Open Source Initiative

Subscribe to Open Source Initiative feed
Updated: 23 hours 53 min ago

OSI Seeks Faculty (YOU!) to Teach New Open Source Courses

Tue, 2019-09-10 09:32
You probably know a little something about Open Source Software?

The OSI is fortunate to include in our membership, board alumni, and business partners some of the world's most renowned innovators and recognized leaders in Open Source Software. Together the OSI community represents every facet of open source, including technical development, business practices, community management, as well as licensing and related legal issues. As more organizations leverage Open Source Software, employers are seeking talent well-versed in open source methods, culture, and management practices to ensure that their investments in open source projects provide the desired benefits for the company, while aligning with the values of, and contributing to, open source communities.

A new educational program...

Together with Brandeis University, we’re launching a new academic specialization in Open Source Technology Management. Although the courses include some technical topics, they are meant to serve the growing demand for technology and organizational managers to work with, support, and participate in open source technology adoption, development, and community.

Teach for us, for all of us!

We’re seeking passionate practitioners, working in and with Open Source Software, to share their knowledge and experience with students interested in the growing number of careers supporting Open Source Software.

These are employment positions, not volunteer roles.

If you are interested, please visit the links above and if you have any questions please feel free to contact Patrick Masson at masson@opensource.org or Ken Udas at kenudas@brandeis.edu. In addition, please feel free to share this information with anyone who might be interested.

Image credit: "OSTMFac01.png" by Open Source Initiative, 2019, CC0 1.0 Universal (CC0 1.0) Public Domain Dedication, is a derivative (cropped, scaled, and color adjusted) of "Double O Arch" a U.S. National Park Service photo, available under Public Domain, via the U.S. National Park Service.

Categories: FLOSS Research

The Mythical Economic Model of Open Source

Thu, 2019-08-15 17:10

It has become fashionable today to study open source through the lens of economic benefits to developers and sometimes draw rather alarming conclusions. It has also become fashionable to assume a business model tie and then berate the open source community, or their licences, for lack of leadership when the business model fails. The purpose of this article is to explain, in the first part, the fallacy of assuming any economic tie in open source at all and, in the second part, go on to explain how economics in open source is situational and give an overview of some of the more successful models.

Open Source is a Creative Intellectual Endeavour

All the creative endeavours of humanity, like art, science or even writing code, are often viewed as activities that produce societal benefit. Logically, therefore, the people who engage in them are seen as benefactors of society, but assuming people engage in these endeavours purely to benefit society is mostly wrong. People engage in creative endeavours because it satisfies some deep need within themselves to exercise creativity and solve problems often with little regard to the societal benefit. The other problem is that the more directed and regimented a creative endeavour is, the less productive its output becomes. Essentially to be truly creative, the individual has to be free to pursue their own ideas. The conundrum for society therefore is how do you harness this creativity for societal good if you can’t direct it without stifling the very creativity you want to harness? Obviously society has evolved many models that answer this (universities, benefactors, art incubation programmes, museums, galleries and the like) with particular inducements like funding, collaboration, infrastructure and so on.

Why Open Source development is better than Proprietary

Simply put, the Open Source model, involving huge freedoms to developers to decide direction and great opportunities for collaboration stimulates the intellectual creativity of those developers to a far greater extent than when you have a regimented project plan and a specific task within it. The most creatively deadening job for any engineer is to find themselves strictly bound within the confines of a project plan for everything. This, by the way, is why simply allowing a percentage of paid time for participating in Open Source seems to enhance input to proprietary projects: the liberated creativity has a knock on effect even in regimented development. However, obviously, the goal for any Corporation dependent on code development should be to go beyond the knock on effect and actually employ open source methodologies everywhere high creativity is needed.

What is Open Source?

Open Source has it’s origin in code sharing models, permissive from BSD and reciprocal from GNU. However, one of its great values is the reasons why people do open source aren’t the same reasons why the framework was created in the first place. Today Open Source is a framework which stimulates creativity among developers and helps them create communities, provides economic benefits to corportations (provided they understand how to harness them) and produces a great societal good in general in terms of published reusable code.

Economics and Open Source

As I said earlier, the framework of Open Source has no tie to economics, in the same way things like artistic endeavour don’t. It is possible for a great artist to make money (as Picasso did), but it’s equally possible for a great artist to live all their lives in penury (as van Gough did). The demonstration of the analogy is that trying to measure the greatness of the art by the income of the artist is completely wrong and shortsighted. Developing the ability to exploit your art for commercial gain is an additional skill an artist can develop (or not, as they choose) it’s also an ability they could fail in and in all cases it bears no relation to the societal good their art produces. In precisely the same way, finding an economic model that allows you to exploit open source (either individually or commercially) is firstly a matter of choice (if you have other reasons for doing Open Source, there’s no need to bother) and secondly not a guarantee of success because not all models succeed. Perhaps the easiest way to appreciate this is through the lens of personal history.

Why I got into Open Source

As a physics PhD student, I’d always been interested in how operating systems functioned, but thanks to the BSD lawsuit and being in the UK I had no access to the actual source code. When Linux came along as a distribution in 1992, it was a revelation: not only could I read the source code but I could have a fully functional UNIX like system at home instead of having to queue for time to write up my thesis in TeX on the limited number of department terminals.

After completing my PhD I was offered a job looking after computer systems in the department and my first success was shaving a factor of ten off the computing budget by buying cheap pentium systems running Linux instead of proprietary UNIX workstations. This success was nearly derailed by an NFS bug in Linux but finding and fixing the bug (and getting it upstream into the 1.0.2 kernel) cemented the budget savings and proved to the department that we could handle this new technology for a fraction of the cost of the old. It also confirmed my desire to poke around in the Operating System which I continued to do, even as I moved to America to work on

Proprietary software.

In 2000 I got my first Open Source break when the product I’d been working on got sold to a silicon valley startup, SteelEye, whose business plan was to bring High Availability to Linux. As the only person on the team with an Open Source track record, I became first the Architect and later CTO of the company, with my first job being to make the somewhat eccentric Linux SCSI subsystem work for the shared SCSI clusters LifeKeeper then used. Getting SCSI working lead to fund interactions with the Linux community, an Invitation to present on fixing SCSI to the Kernel Summit in 2002 and the maintainership of SCSI in 2003. From that point, working on upstream open source became a fixture of my Job requirements but progressing through Novell, Parallels and now IBM it also became a quality sought by employers.

I have definitely made some money consulting on Open Source, but it’s been dwarfed by my salary which does get a boost from my being an Open Source developer with an external track record.

The Primary Contributor Economic Models

Looking at the active contributors to Open Source, the primary model is that either your job description includes working on designated open source projects so you’re paid to contribute as your day job or you were hired because of what you’ve already done in open source and contributing more is a tolerated use of your employer’s time, a third, and by far smaller group is people who work full-time on Open Source but fund themselves either by shared contributions like patreon or tidelift or by actively consulting on their projects. However, these models cover existing contributors and they’re not really a route to becoming a contributor because employers like certainty so they’re unlikely to hire someone with no track record to work on open source, and are probably not going to tolerate use of their time for developing random open source projects. This means that the route to becoming a contributor, like the route to becoming an artist, is to begin in your own time.

Users versus Developers

Open Source, by its nature, is built by developers for developers. This means that although the primary consumers of open source are end users, they get pretty much no say in how the project evolves. This lack of user involvement has been lamented over the years, especially in projects like the Linux Desktop, but no real community solution has ever been found. The bottom line is that users often don’t know what they want and even if they do they can’t put it in technical terms, meaning that all user driven product development involves extensive and expensive product research which is far beyond any open source project. However, this type of product research is well within the ability of most corporations, who can also afford to hire developers to provide input and influence into Open Source projects.

Business Model One: Reflecting the Needs of Users

In many ways, this has become the primary business model of open source. The theory is simple: develop a traditional customer focussed business strategy and execute it by connecting the gathered opinions of customers to the open source project in exchange for revenue for subscription, support or even early shipped product. The business value to the end user is simple: it’s the business value of the product tuned to their needs and the fact that they wouldn’t be prepared to develop the skills to interact with the open source developer community themselves. This business model starts to break down if the end users acquire developer sophistication, as happens with Red Hat and Enterprise users. However, this can still be combatted by making sure its economically unfeasible for a single end user to match the breadth of the offering (the entire distribution). In this case, the ability of the end user to become involved in individual open source projects which matter to them is actually a better and cheaper way of doing product research and feeds back into the synergy of this business model.

This business model entirely breaks down when, as in the case of the cloud service provider, the end user becomes big enough and technically sophisticated enough to run their own distributions and sees doing this as a necessary adjunct to their service business. This means that you can no-longer escape the technical sophistication of the end user by pursuing a breadth of offerings strategy.

Business Model Two: Drive Innovation and Standardization

Although venture capitalists (VCs) pay lip service to the idea of constant innovation, this isn’t actually what they do as a business model: they tend to take an innovation and then monetize it. The problem is this model doesn’t work for open source: retaining control of an open source project requires a constant stream of innovation within the source tree itself. Single innovations get attention but unless they’re followed up with another innovation, they tend to give the impression your source tree is stagnating, encouraging forks. However, the most useful property of open source is that by sharing a project and encouraging contributions, you can obtain a constant stream of innovation from a well managed community. Once you have a constant stream of innovation to show, forking the project becomes much harder, even for a cloud service provider with hundreds of developers, because they must show they can match the innovation stream in the public tree. Add to that Standardization which in open source simply means getting your project adopted for use by multiple consumers (say two different clouds, or a range of industry). Further, if the project is largely run by a single entity and properly managed, seeing the incoming innovations allows you to recruit the best innovators, thus giving you direct ownership of most of the innovation stream. In the early days, you make money simply by offering user connection services as in Business Model One, but the ultimate goal is likely acquisition for the talent possesed, which is a standard VC exit strategy.

All of this points to the hypothesis that the current VC model is wrong. Instead of investing in people with the ideas, you should be investing in people who can attract and lead others with ideas

Other Business Models

Although the models listed above have proven successful over time, they’re by no means the only possible ones. As the space of potential business models gets explored, it could turn out they’re not even the best ones, meaning the potential innovation a savvy business executive might bring to open source is newer and better business models.

Conclusions

Business models are optional extras with open source and just because you have a successful open source project does not mean you’ll have an equally successful business model unless you put sufficient thought into constructing and maintaining it. Thus a successful open source start up requires three elements: A sound business model, or someone who can evolve one, a solid community leader and manager and someone with technical ability in the problem space.

If you like working in Open Source as a contributor, you don’t necessarily have to have a business model at all and you can often simply rely on recognition leading to opportunities that provide sufficient remuneration.

Although there are several well known business models for exploiting open source, there’s no reason you can’t create your own different one but remember: a successful open source project in no way guarantees a successful business model.

About the author: James Bottomley is a Distinguished Engineer at IBM Research where he works on Cloud and Container technology. He is also Linux Kernel maintainer of the SCSI subsystem. He has been a Director on the Board of the Linux Foundation and Chair of its Technical Advisory Board. "The Mythical Economic Model of Open Source" ©James Bottomley, 2019, Attribution 4.0 International (CC BY 4.0) via James Bottomley's random Pages. Reposted here with permission, under an Attribution 4.0 International (CC BY 4.0) license.

Image credit: "Mythical.png" by Open Source Initiative, 2019, CC0 1.0 Universal (CC0 1.0) Public Domain Dedication, is a derivative (cropped and color adjusted) of "Pothole Point" a U.S. National Park Service photo, available under Public Domain, via the U.S. National Park Service.

Categories: FLOSS Research

Open Source Success in Schools - Something to make a "FUSS" about

Tue, 2019-08-06 16:59

Since he was a child, Marco Marinello has always found computers and how they operate intriguing. His father introduced him to the world of computer science early, including the basics of Linux system administration. Fortunately his own school — and in fact all of the South Tyrol region where he lives — runs a modified version of Debian (“Free Upgrade in Southtyrol's Schools” or “FUSS") for both administrative computing, and significantly for Marco, on student laptops as well. Free and Open Source Software provides schools and students unique educational opportunities while enhancing the technology services offered to teachers, administrators, families, and ultimately the community they serve.

Motivated by his own interests and with the support of the Bozen-Bolzano School District and staff, Marco began volunteering with the maintenance of his local school network. The opportunity to work hands-on with the technology, learn from working professionals, and help his community, fostered his curiosity and promoted exploration of computers and computing: he soon found himself programming, teaching himself HTL and Python.

Screenshot of the latest version of FUSS (©Paolo Dongilli. License: CC BY-SA 4.0)

With continued opportunities, only made possible through the Bozen-Bolzano schools commitment to Free and Open Source Software, Marco began working on the FUSS project directly. His first project was to port the FUSS distribution to armhf, and the installation of RaspberryPis in a Bolzano high school computer lab. The work not only provided Marco with the technical education one might expect, but with presentations to both his school’s teachers and technicians as well as the local Linux User Group, important lessons in writing and communications followed.

Marco Marinello with Piergiorgio Cemin, teacher and FUSS Project member (©Emiliano Vavassori. License: CC BY-SA 4.0)

“I think that FUSS gave me the very important opportunity to approach and learn the importance of free software and I’m therefore very grateful.”
— Marco Marinello, student and developer.

 

A workshop held by Marco Marinello in 2016 (©Emiliano Vavassori. License: CC BY-SA 4.0)

Marco’s initial success led to many other projects — and learning opportunities: “PyHearings,” a project for parents to book appointments with teachers, and “Gestione piano di Aggiornamento” a teachers’ training portal, a complete web-application based on Django, that automates the district’s previous process (that required 20 employees). Fully embracing the “open ethos” Marco also contributed to existing projects integrated with FUSS like, OctoMon (the district’s central monitoring system) and OctoNet (the district’s management tool). And to make his Free and Open Source experience complete, Marco has presented on Django and LibreOffice Online: again highlighting that the activities undertaken, and skills acquired, aren’t just technical. With dedicated staff and creative administrators, Free and Open Source Software can be a valuable addition, enhancing the school’s entire curriculum.

Considering the success of students like Marco, and the FUSS program itself, we reached out to Paolo Dongilli, Technical Inspector for the Italian School Board of the Autonomous Province of Bozen-Bolzano, to learn more about the program, it’s inception, and where it is headed. We hope the experiences of the Bozen-Bolzano schools can help other schools recognize the opportunities of Free and Open Source Software to extend technology resources and contribute to educational programs.

One of the IT-labs with FUSS - Middle School “Ada Negri” in Bolzano (©Paolo Dongilli. License: CC BY-SA 4.0)

Open Source Initiative (OSI): Can you tell us a little about the schools, school district, and Bozen/Bolzano Area?

Paolo Dongilli: The Autonomous Province Bozen – South Tyrolis is located in Northern Italy with a population of just over 525,000 people. Because of its location, along the Italian and Austrian border, residents may speak Italian, German, or Ladin, a native language common the Dolomite Mountains. As one can imagine, with such a diverse community living within a politically autonomous region, our schools face many challenges in accommodating learners’ educational needs, while respecting our many cultures, and compiling with independent local and regional governments. The school system serving the community thus includes 44,000 students attending 78 German language schools; 17,000 students in Italian language schools; and another 2,500 students in Ladin language schools. Even more interesting (i.e. challenging), is that each of these three language-based school systems have their own school boards.

OSI: What is your background in technology generally, and with open source and GNU/Linux specifically?

Paolo Dongilli: I graduated in 1998 with a degree in Computer Science Engineering, and began working in Computational Linguistics at EURAC Research, then for the Free University of Bozen-Bolzano.

In 2008 I left research and joined the ICT Division of the Province of Bozen-Bolzano where, I worked for the ICT Strategy and Planning Office in the Enterprise Architecture Group which, in 2016, led to a position with the Italian School Board of South Tyrol to coordinate FUSS (Free Upgrade South Tyrol's Schools).

I started exploring the Free and Open Source Software world during the 90s, when I was studying at the university. When I came back to Bolzano I and some friends founded Linux User Group Bolzano-Bozen-Bulsan to help spread the use of FLOSS and GNU/Linux in South Tyrol.

OSI: What were some of the key drivers, issues, circumstances that led to your interest in introducing open source and GNU/Linux to the school district?

Paolo Dongilli: Open Source Software can be extremely helpful to both students and schools. A perfect example of this would be by looking at Bozen-Bolzano schools. FUSS is a complete GNU/Linux solution, server, client and desktop / standalone, based on Debian for the management of our school network. Importantly, the project provides and promotes, “digital sustainability,” allowing students and teachers to use at home the same tools installed at school, freely and without any cost for families.

OSI: What barriers did you have to overcome throughout the process of introducing and implementing your plan?

Paolo Dongilli: From the very beginning [January 2005], the concept of Free Software in schools was favored by local political parties and school directors of the Italian language schools. A key motivation during planning was the opportunity for students and teachers to use the same software at school and at home, without any additional costs to families. Planners were also aware they were Investing public money, and felt the project could spark new educational projects: creating new software and manuals, reusing and modifying existing software, sharing the new outcome with the world.

In addition to the benefits related to access and academics, planners believed FLOSS would provide financial savings, compared to purchasing expensive recurring licenses from vendors like Microsoft, while also extending the life of hardware through open source alternatives. https://docs.italia.it/italia/piano-triennale-ict/codice-amministrazione-digitale-docs/it/v2018-09-28/

As one might expect, we experienced the typical barriers from people who did not want to exit their comfort zone, or did not appreciate the importance of investing public money in schools in a sustainable way. Fortunately those people were a minority: our teachers understood the importance of this change and the pupils started using GNU/Linux without any difficulty.

Paolo Dongilli presenting at SFSCon 2018 (©Patrick Masson. License: CC BY-SA 4.0)

OSI: How did the transition go? How did you raise awareness, gain support, address concerns, confront objections?

Paolo Dongilli: The project was financed by the European Social Fund, supported and sponsored by the Italian School Board of the Autonomous Province of Bolzano, administratively managed by the Professional Training Institute “Luigi Einaudi” of Bolzano, in collaboration with the Italian Schools Board, and with the advice and collaboration of the IT firm Truelite Srl as technological partner. A strong synergy and convergence of intent was created between politics, public, and private sectors, and the planning phase of the FUSS project began in January 2005, with a deployment phase during the summer of that year. The project went live in September at the beginning of the new school year.

OSI: How did the implementation go, technically, culturally, academically?

Paolo Dongilli: The project included an analysis of the state of hardware across the district, the preparation of software packages — such as the FUSS-server (configuration of services on the server side), and FUSS-client — and the development of a variety of tools to make the server and client installation simpler and automated. We also worked to identify open source alternatives to existing applications used across the district.

Over the years other services were added, such as Octofuss (server and user management), Octomon (technical monitoring of installations), a VPN network that connects all schools, servers with e-learning platforms (Moodle and Chamilo), VOIP services for some schools, just to mention the most significant.

We also developed and implemented a comprehensive training course for the administration of the systems. This included seven teachers and one administrator (The FUSS Group) who were charged with not only managing the technical side (hardware and software), but just as importantly, carry out our educational and client-side support activities, helping teaching staff and students fully maximize the resources available with the new FUSS environment.

A FUSS Group operates in every Italian school in South Tyrol meeting local needs, and becomes, in time, a point of reference and advice for all educational activities using information and communication technologies (ICT). Today, the FUSS Group also proposes new tools and services based on Debian or derivatives (Ubuntu, Mint), recommends updates suitable to specific teaching and learning needs, and assesses requests from teachers. All requests are considered.

All this without forgetting the fundamental purpose: to support colleagues and students in the use of ICT on a daily basis for teaching and learning.

OSI: How did you measure success, and did you meet those expectations?

Paolo Dongilli: Success is measured in many ways. First sustainability: the ability of teachers and students to accomplish their daily work, meet educational objectives, and perform administrative tasks, through Free and Open Source Software. Secondly, influencing best-practices: the adoption of LibreOffice and open (document) formats in education positively influenced our local public administration which now uses and keeps LibreOffice up-to-date. And most importantly, educational value: the participation of students studying, modifying, creating, and publishing Free and Open Source Software and documentation, flipping the classroom and showing their efforts to colleagues and teachers.

OSI: What failed, or did not go as expected?

Paolo Dongilli: As the saying goes: “nemo propheta in patria sua,” i.e. “nobody is a prophet in his own land.” Although we’ve been successful for almost fifteen years, FUSS has never been able to spread beyond our Italian language schools, to the German and Ladin language schools within South Tyrol. We’ve been unable to or make headway with ethical reasons/arguments, didactic advantages of Free and Open Source Software over proprietary software, or even through demonstrated cost savings, which can then be invested in faculty development or new educational initiatives.

OSI: What is the program like today?

Paolo Dongilli: Today governance is provided by the Italian School Board, through the “FUSS Lab for Digital Sustainability in Schools”.

FUSS Digital Sustainability Laboratory at Liceo “Toniolo” (©Paolo Dongilli. License CC BY-SA 4.0)

The FUSS Lab is composed by 4 people (Piergiorgio Cemin, Massimo Previdi, Claudio Cavalli, and myself) in collaboration with Mauro Valer, inspector for the MINT subjects and the great support of Marco Marinello who has been helping with great passion since when he was in middle school. In September Piergiorgio Cemin, after many years of teaching and support for the project will retire and Massimo Previdi will bring back his experience to the high school (IISS “Galileo Galilei”) where he has been teaching. They will be substituted in the team by Andrea Bonani, teacher and former coordinator of the project, and Stefania Fiore, also teacher and open source enthusiast.

A group of 12 GNU/Linux professionals (7 FTE) of the Province of Bolzano IT division (FUSS Technicians) provides technical assistance, maintaining all the networks, clients, servers, and available devices in all schools doing a great job every day.

Our current footprint includes 64 servers and around 4,000 PCs and notebooks. Current staffing support includes at least one teacher at each school serving as the “FUSS referent,” with a total of approximately 70 teachers across the district who act as points of contact for FUSS technicians. These teams serve to assist other non-technical staff and students, undertake maintenance, and respond to requests related to installed software, new software, or training needs.

A few important notes about our outreach activities. First, according to Article 69 of the National Code for  Digital Administration, every line of code we develop as part of the FUSS project is distributed under the GPLv3, with all documentation carrying a CC BY- SA license. We’re also working directly with the community to share our work, and increase the use of Free and Open Source Software outside of schools. For example, a group of volunteers from the Linux User Group Bozen-Bolzano, and the Group “Digital Sustainability South Tyrol - Alto Adige”, offer twice monthly workshops  in 4 different cities (Bozen, Meran, Bruneck, and Brixen) to help the public install Linux on PCs and notebooks. These volunteers provide demonstrations and training on how to use the the GNU/Linux operating system, and the most common software packages, such as LibreOffice (a real favorite among community participants).

OSI: What would be your three best pieces of advice for others considering implementing open source within their own schools and districts?

Paolo Dongilli: First of all, don’t reinvent the wheel, i.e. look around to see if there are examples from other organizations that you can follow and software you can reuse. We at the FUSS Project are happy to share with you our experience and lessons learned over the past 14 years. Write to us: info@fuss.bz.it. We’re happy to share all we have: multilingual distributions for both servers and clients — all Debian — with additional packages to make configuration on school networks easier, and a series of metapackages to group the most common packages needed in elementary, middle and high schools.

I’d also suggest, when presenting a project plan to your school or school district, in addition to highlighting all the technical and economic advantages, emphasize how “sustainable digitalization,” based on Free and Open Source Software, open formats, and free didactic material, improves knowledge sharing, fosters non-traditional educational opportunities, and extends access to students and families who may not have access to proprietary systems.

Also, don’t underestimate the importance (and value) of communication with, and training of users (teachers, principals, pupils and their families) through your local Free and Open Source Software community.

Lastly, invest money in people — motivated people, no matter what their role, technicians, developers, teachers, students — instead of spending money in renewing proprietary software licenses (i.e. operating expenses) in your school. Remember that when you spend money developing new FOSS or enhancing existing FOSS you also invest money (i.e. capital  expenses). Share all what you do and create (software, documentation, didactic material), especially if you use public money

Categories: FLOSS Research

Open Source in 2019

Tue, 2019-07-30 15:50

21 years in, the landscape around open source evolved a lot. But is, "open source" enough? According to Thierry Carrez, VP of Engineering at OSI Affiliate Member OpenStack Foundation, open source is necessary, but it is not sufficient. In this post he'll detail why.

Why open source is necessary today What open source is

Free software started in the 80’s by defining a number of freedoms. The author of free software has to grant users (and future contributors to the software) those freedoms. To summarize, those freedoms made you free to study, improve the software, and distribute your improvements to the public, so that ultimately everyone benefits. That was done in reaction to the apparition of "proprietary" software in a world that previously considered software a public good.

When open source was defined in 1998, it focused on a more specific angle: the rights users of the software get with the software, like access to the source code, or lack of constraints on usage. This straight focus on user rights (and less confusing naming) made it much more understandable to businesses and was key to the success of open source in our industry today.

Despite being more business-friendly, open source was never a "business model". Open source, like free software before it, is just a set of freedoms and rights attached to software. Those are conveyed through software licenses and using copyright law as their enforcement mechanism. Publishing software under a F/OSS license may be a component of a business model, but if is the only one, then you have a problem.

Freedoms

The freedoms and rights attached to free and open source software bring a number of key benefits for users.

The first, and most-often cited of those benefits is cost. Access to the source code is basically free as in beer. Thanks to the English language, this created interesting confusion in the mass-market as to what the "free" in "free software" actually meant. You can totally sell "free software" -- this is generally done by adding freedoms or bundling services beyond what F/OSS itself mandates (and not by removing freedoms, as some recently would like you to think).

If the cost benefit has proven more significant as open source evolved, it's not because users are less and less willing to pay for software or computing. It's due to the more and more ubiquitous nature of computing. As software eats the world, the traditional software pay-per-seat models are getting less and less adapted to how users work, and they create extra friction in a world where everyone competes on speed.

As an engineer, I think that today, cost is a scapegoat benefit. What matters more to users is actually availability. With open source software, there is no barrier to trying out the software with all of its functionality. You don't have to ask anyone for permission (or enter any contractual relationship) to evaluate the software for future use, to experiment with it, or just to have fun with it. And once you are ready to jump in, there is no friction in transitioning from experimentation to production.

As an executive, I consider sustainability to be an even more significant benefit. When an organization makes the choice of deploying software, it does not want to left without maintenance, just because the vendor decides to drop support for the software you run, or just because the vendor goes bankrupt. The source code being available for anyone to modify means you are not relying on a single vendor for long-term maintenance.

Having a multi-vendor space is also a great way to avoid lock-in. When your business grows a dependency on software, the cost of switching to another solution can get very high. You find yourself on the vulnerable side of maintenance deals. Being able to rely on a market of vendors providing maintenance and services is a much more sustainable way of consuming software.

Another key benefit of open source adoption in a corporate setting is that open source makes it easier to identify and attract talent. Enterprises can easily identify potential recruits based on the open record of their contributions to the technology they are interested in. Conversely, candidates can easily identify with the open source technologies an organization is using. They can join a company with certainty that they will be able to capitalize on the software experience they will grow there.

A critical benefit on the technical side is transparency. Access to the source code means that users are able to look under the hood and understand by themselves how the software works, or why it behaves the way it does. Transparency also allows you to efficiently audit the software for security vulnerabilities. Beyond that, the ability to take and modify the source code means you have the possibility of self-service: finding and fixing issues by yourself, without even depending on a vendor. In both cases that increases your speed in reacting to unexpected behavior or failures.

Last but not least: with open source you have the possibility to engage in the community developing the software, and to influence its direction by contributing directly to it. This is not about "giving back" (although that is nice). Organizations that engage in the open source communities are more efficient, anticipate changes, or can voice concerns about decisions that would adversely affect them. They can make sure the software adapts to future needs by growing the features they will need tomorrow.

Larger benefits for ecosystems

Beyond those user benefits (directly derived from the freedoms and rights attached to F/OSS), open source software also has positive effects to wider ecosystems.

Monopolies are bad for users. Monocultures are vulnerable environments. Open source software allows challengers to group efforts and collaborate to build an alternative to the monopoly player. It does not need to beat or eliminate the proprietary solution -- being successful is enough to create a balance and result in a healthier ecosystem.

Looking at the big picture, we live on a planet with limited natural goods, where reducing waste and optimizing productivity is becoming truly critical. As software gets pervasive and more and more people produce it, the open source production model reduces duplication of effort and the waste of energy of having the same solutions developed in multiple parallel proprietary silos.

Finally, I personally think a big part of today's social issues is the result of artificially separating our society between producers and consumers. Too many people are losing the skills necessary to build things, and are just given subscriptions, black boxes and content to absorb in a well-oiled consumption machine. Free and open source software blurs the line between producers and consumers by removing barriers and making every consumer a potential producer. It is part of the solution rather than being part of the problem.

All those benefits explain why open source software is so successful today. Those unique benefits ultimately make a superior product, one that is a smart choice for users. It is also a balancing force that drives good hygiene to wider ecosystems, which is why I would go so far as saying it is necessary in today's world.

 

Open source is not enough The relative victory of open source

Open source is everywhere today. It has become the default way to build and publish software. You can find open source on every server, you can find open source on every phone... Even Microsoft, the company which basically invented proprietary software, is heavily adopting open source today, with great success. By all accounts, open source won.

But... has it, really ?

The server, and by extension the computing, networking, and storage infrastructure, are unquestionably dominated by open source. But the growing share of code running operations for this infrastructure software is almost always kept private. The glue code used to provide users access to this infrastructure (what is commonly described as "cloud computing") is more often than not a trade secret. And if you look to the other side, the desktop (or the user-side applications in general) are still overwhelmingly driven by proprietary software.

Even contemplating what are generally considered open source success stories, winning can leave a bitter taste in the mouth. For example, looking at two key tech successes of the last 10 years, Amazon Web Services and Android, they both are heavily relying on open source software. They are arguably a part of this success of open source picture I just painted. But if you go back and look at all the user benefits I listed, the users of AWS and Android don’t really enjoy them all. As an AWS user, you don't have transparency: you can’t really look under the hood and understand how AWS runs things, or why the service behaves the way it does. As an Android user, you can’t really engage with Android upstream, contribute to the creation of the software and make sure it serves your needs better tomorrow.

So open source won and is ubiquitous... however in most cases, users are denied some of the key benefits of open source. And looking at what is called "open source" today, one can find lots of twisted production models. By "twisted", I mean models where some open source benefits go missing, like the ability to efficiently engage in the community.

For example, you find single-vendor open source, where the software is controlled by a single company doing development behind closed doors. You find open-core open source, where advanced features are reserved for a proprietary version and the open source software is used as a trial edition. You find open source code drops, where an organization just periodically dumps their code to open-wash it with an open source label. You find fire and forget open source, where people just publish once on GitHub with no intention of ever maintaining the code. How did we get here?

Control or community

What made open source so attractive to the software industry was the promise of the community. An engaged community that would help them write the software, build a more direct relationship that would transcend classic vendor links, and help you promote the software. The issue was, those companies still very much wanted to keep control: of the software, of the design, of the product roadmap, and of the revenue. And so, in reaction to the success of open source, the software industry evolved a way to produce open source software that would allow them to retain control.

But the fact is... you can’t really have control and community. The exclusive control by a specific party over the code is discouraging other contributors from participating. The external community is considered as free labor, and is not on a level playing field compared to contributors on the inside, who really decide the direction of the software. This is bound to create frustration. This does not make a sustainable community, and ultimately does not result in sustainable software.

The open-core model followed by some of those companies creates an additional layer of community tension. At first glance, keeping a set of advanced features for a proprietary edition of the software sounds like a smart business model. But what happens when a contributor proposes code that would make the "community edition" better ? Or when someone starts to question why a single party is capitalizing on the work of "the community"? In the best case, this leads to the death of the community, and in the worst case this leads to a fork... which makes this model particularly brittle.

By 2019, I think it became clearer to everyone that they have to choose between keeping control and growing a healthy community. However most companies chose to retain control, and abandon the idea of true community contribution. Their goal is to keep reaping the marketing gains of calling their software open source, of pretending to have all the benefits associated with the open source label, while applying a control recipe that is much closer to proprietary software than to the original freedoms and rights associated with free software and open source.

How open source is built impacts the benefits users get

So the issue with twisted production models like single-vendor or open-core is that you are missing some benefits, like availability, or sustainability, or self-service, or the ability to engage and influence the direction of the software. The software industry adapted to the success of open source: it adopted open source licenses but little else, stripping users of the benefits associated with open source while following the letter of the open source law.

How is that possible?

The issue is that free software and open source both addressed solely the angle of freedom and rights that users get with the end product, as conveyed through software licenses. They did not mandate how the software was to be built. They said nothing about who really controls the creation of the software. And how open source is built actually has a major impact on the benefits users get out of the software.

The sad reality is, in this century, most open source projects are actually closed one way or the other: their core development may be done behind closed doors, or their governance may be locked down to ensure permanent control by the main sponsor. Everyone produces open source software, but projects developed by a truly open community have become rare.

And yet, with truly open communities, we have an open source production model that guarantees all the benefits of free and open source software. It has a number of different names. I call it open collaboration: the model where a community of equals contributes to a commons on a level playing field, generally under an open governance and sometimes the asset lock of a neutral non-profit organization. No reserved seats, no elite group of developers doing design behind closed doors. Contribution is the only valid currency.

Open collaboration used to be the norm for free and open source software production. While it is more rare today, the success of recent open infrastructure communities like OpenStack or Kubernetes proves that this model is still viable today at very large scale, and can be business-friendly. This model guarantees all the open source benefits I listed above, especially sustainability (not relying on a single vendor), and the ability for anyone to engage, influence the direction of the software, and make sure it addresses their future needs.

As much as I may regret it, the software industry is free to release their closely-developed software under an open source license. They have every right to call their software "open source", as long as they comply with the terms of an OSI-approved license. So if we want to promote good all-benefits-included open source against twisted some-benefits-withheld open source, F/OSS advocates will need to regroup, work together, reaffirm the Open Source Definition and build additional standards on top of it, beyond "open source".

 

What we should do about it

So while being necessary, open source today is not enough. What should we, open source enthusiasts and advocates, do about that ? First, let me clarify what we should not do.

This is not a call to change open source

Since open source was coined in 1998, software companies have evolved ways to retain control while producing open source software, and in that process stripped users of some of the traditional benefits associated with F/OSS. But those companies were still abiding to the terms of the open source licenses, giving users a clear base set of freedoms and rights.

Over the past year, a number of those companies have decided that they wanted even more control, in particular control of any revenue associated with the open source software. They proposed new licenses, removing established freedoms and rights in order to be able to assert that level of control. The Open Source Definition defines those minimal freedoms and rights that any open source software should have, so the Open Source Initiative (OSI), as steadfast guardians of that definition, rightfully resisted those attempts.

Those companies quickly switched to attacking OSI's legitimacy, pitching "Open Source" more as a broad category than a clear set of freedoms and rights. And they created new licenses, with deceptive naming ("community", "commons", "public"...) in an effort to blur the lines and retain some of the Open Source Definition aura for their now-proprietary software.

The solution is not in redefining open source, or claiming it's no longer relevant. Open source is not a business model, or a constantly evolving way to produce software. It is a base set of user freedoms and rights expressed in the license the software is published under. Like all standards, its value resides in its permanence.

Yes, I'm of the opinion that today, "open source" is not enough. Yes, we need to go beyond open source. But in order to do that, we need to base that additional layer on a solid foundation: the Open Source Definition.

That makes the work of the OSI more important than ever. Open source used to be attacked from the outside, proprietary software companies claiming open source software was inferior or dangerous. Those were clear attacks that were relatively easy to resist: it was mostly education and advocacy, and ultimately the quality of open source software could be used to prove our point. Now it's attacked from the inside, by companies traditionally producing open source software, claiming that it should change to better fit their business models. We need to go back to the basics and explain why those rights and freedoms matter, and why blurring the lines ultimately weakens everyone. We need a strong OSI to lead that new fight, because it is far from over.

A taxonomy of open source production models

As I argued in previous parts, how open source is built ultimately impacts the benefits users get. A lot of us know that, and we all came up with our own vocabulary to describe those various ways open source is produced today.

Even within a given model (say open collaboration between equals on a level playing field), we use different sets of principles: the OpenStack Foundation has the 4 Opens (open source, open development, open design, open community), the Eclipse Foundation has the Open Source Rules of Engagement (open, transparent, meritocracy), the Apache Foundation has the Apache Way... We all advocate for our own variant, focusing on differences rather than what we have in common: the key benefits those variants all enable.

This abundance of slightly-different vocabulary makes it difficult to rally around and communicate efficiently. If we have no clear way to differentiate good all-benefits-included open source from twisted some-benefits-withheld open source, the confusion (where all open source is considered equal) benefits the twisted production models. I think it is time for us to regroup, and converge around a clear, common classification of open source production models.

We need to classify those models based on which benefits they guarantee to the users of the produced software. Open-core does not guarantee availability, single-vendor does not provide sustainability nor does it allow to efficiently engage and influence the direction of the software, while open-collaboration gives you all three.

Once we have this classification, we'll need to heavily communicate around it, with a single voice. As long as we use slightly different terms (or mean slightly different things when using common terms), we maintain confusion which ultimately benefits the most restrictive models.

Get together

Beyond that, I think we need to talk more. Open source conferences used to be all about education and advocacy: what is this weird way of producing software, and why you should probably be interested in it. Once open source became ubiquitous, those style of horizontal open source conferences became less relevant, and were soon replaced by more vertical conferences around a specific stack or a specific use case.

This is a good evolution: this is what winning looks like. The issue is: the future of open source is not discussed anymore. We rest on our laurels, while the world continually evolves and adapts. Some open source conference islands may still exist, with high-level keynotes still raising the issues, but those are generally one-way conversations.

To do this important work of converging vocabulary and defining common standards on how open source is produced, Twitter won't cut it. To bootstrap the effort we'll need to meet, get around a table and take the time to discuss specific issues together. Ideally that would be done around some other event(s) to avoid extra travel.

And we need to do that soon. This work is becoming urgent. "Open source" as a standard has lots of value because of all the user benefits traditionally associated with free and open source software. That created an aura that all open source software still benefits from today. But that aura is weakening over time, thanks to twisted production models. How much more single-vendor open source can we afford until "open source" no longer means you can engage with the community and influence the direction of the software?

So here is my call to action...

In 2019, open source is more important than ever. Open source has not "won", this is a continuous effort, and we are today at a critical junction. I think open source advocates and enthusiasts need to get together, defining clear, standard terminology on how open source software is built, and start communicate heavily around it with a single voice. And beyond that, we need to create forums where those questions on the future of open source are discussed. Because whatever battles you win today, the world does not stop evolving and adapting.

Obviously I don't have all the answers. And there are lots of interesting questions. It's just time we have a place to ask those questions and discuss the answers. If you are interested and want to get involved, feel free to contact me.

About the author: Thierry Carrez is VP of Engineering at OSI Affiliate Member OpenStack Foundation and an elected member of the OpenStack Technical Committee. "Open Source in 2019," parts 1/3, 2/3 & 3/3, © Thierry Carrez, 2019, via ttx:reloaded. Reposted here with permission, under a Creative Commons Attribution-ShareAlike 4.0 International License.

Image credit: "OpenSourceIN2019_0.png" by Open Source Initiative, 2019, CC0 1.0 Universal (CC0 1.0) Public Domain Dedication, is a derivative of "Hikers on the Boardwalk Through the Steam at Grand Prismatic Spring" a U.S. National Park Service photo by Jacob W. Frank (2016), availabe under Public Domain, via the U.S. National Park Service.

Categories: FLOSS Research

Brandeis University and Open Source Initiative to Launch New Educational Partnership.

Wed, 2019-07-17 00:37

Resources designed to fill key skills gaps as open source industry matures.

OSCON – PORTLAND, OR – July 17, 2019 – Brandeis University’s Graduate Professional Studies division (GPS) will partner with The Open Source Initiative® (OSI) to provide new educational offerings for the open source community, the university announced at OSCON 2019.

As more companies start leveraging Open Source Software to reduce costs, decrease time to deployment and foster innovation, the organizations that have realized success as open source consumers are now extending their participation within open source communities as collaborators and contributors. This shift can create new challenges to traditional business processes and models, requiring dedicated policies, programs and personnel to ensure that the investments in open source projects produce the desired benefits while still aligning with the values of the open source communities. The Brandeis GPS-OSI partnership will help address the growing demand for expertise within organizations seeking to authentically collaborate with, and productively manage, open source resources.

“Understanding how to assess, engage, and contribute to open source communities while also delivering value to your company is the next generation skill set employers are looking for,” said Patrick Masson, general manager of the Open Source Initiative. “We're thrilled to work with Brandeis to help continue the incredible growth of open source software and projects.”

True to open source software process and principles, the educational offerings coming out of the partnership will be crowd-sourced and jointly developed by an advisory board comprised of university curriculum development experts and senior open source advocates from Amazon, Red Hat, Bloomberg, Twitter and other leading companies.

“Brandeis GPS is known for developing programs that keep a finger on the pulse of what’s happening in technology,” said Dr. James La Creta, the university’s chief information officer and chair of the Master of Science in Technology Management program. “Much like the other graduate programs at Brandeis GPS, open source technology's flexibility, speed, and cost-effectiveness makes it extremely desirable for organizations. It yields a better quality product, creates a culture of collaboration, and attracts curious and innovative talent that all CIO's covet.”

Courses and other initiatives are currently in development, and the university expects to announce more information about the first open source educational program later this year. Visit www.brandeis.edu/open-source to learn more.

About Brandeis Graduate Professional Studies
Brandeis University’s Graduate Professional Studies division (GPS) offers fully online, part-time graduate programs, specializations, and professional development courses in today’s most in-demand fields. With graduate programs that include Technology Management, Information Security Leadership, User-Centered Design, and Digital Innovation for FinTech, Brandeis GPS strives to provide programs that empower students to be on the leading edge of advancements in technology and innovation. Courses are led by industry experts who deliver professional insights and individualized support. Brandeis GPS is dedicated to extending the rigorous academic standards that make Brandeis University one of the top institutions in the country to a diverse population seeking to advance their careers through continuing studies.

About The Open Source Initiative
Founded in 1998, The Open Source Initiative 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 public charity with global vision based in California. For more information about the OSI, please see, opensource.org.

Categories: FLOSS Research

Juniper Networks Extends Commitment to Open Source Software and Communities through Open Source Initiative Sponsorship.

Sun, 2019-07-14 13:52

Generous support from long-standing open source collaborator and contributor will advance open source alignment and foster open standards.

OSCON, Portland, OR - July 15, 2019 – The Open Source Initiative ® (OSI), the founding organization of the Open Source Software movement and steward of the Open Source Definition, announced today corporate sponsorship by Juniper Networks, the longstanding proponent of open source software and open standards, and industry leader in automated, scalable, and secure networks. Juniper Networks firmly believes open source and open standards foster greater innovation, and for years has actively participated in a variety of open source communities and key standards bodies, including FreeBSD Foundation, Linux Foundation, Cloud Native Computing Foundation, and OpenStack Foundation. In addition to their support of open source foundations, the networking company has released or contributed to many free and open source projects such as OpenStack, Ansible, Salt, PyEZ, wistar, OpenNTI, Tungsten Fabric, along with dozens of others.

“Open source has never been more fundamental to technology innovation today, forming the building blocks for widely used platforms in networks, clouds and applications in every industry sector.” said Randy Bias, VP of Technology and Open Source Software. “Juniper supports the OSI’s key role in articulating and defending the principles on which open source is based, especially as the technologies in which open source is used rapidly evolve and respond to competitive and regulatory pressures.”

“Open source has meaning,” added VM (Vicky) Brasseur, Director of Open Source Strategy at Juniper Networks. “It means a lot to Juniper Networks, which recognises the benefits it receives from using Open Source Software and its responsibilities to the communities that build that software. That meaning extends beyond the software to the term itself, as represented in the Open Source Definition (OSD). Without this shared and standard definition, Juniper and other enterprises could not communicate and operate effectively. We at Juniper are grateful for the dedication that OSI has shown over the past and future years to protecting the Open Source Definition and the meaning of open source.”

As more and more companies shift from being consumers of open source to contributors—or even creators—of open source, many face internal challenges: executive buy-in, re-orienting middle management, re-engineering internal processes, and identifying compatible business models that don’t just work with open source (or conflict with it), but actually leverage its power to innovate and differentiate. These are the issues now front and center for so many seeking the benefits and successes of Open Source Software, and this is exactly where the OSI is focusing work today: continuing efforts in awareness and adoption, while expanding work to promote authenticity and foster sustainability.

Support from the world’s leading technology companies, like Juniper Networks, is critical for not only the financial contributions that keep OSI operational, but also for their role as exemplars who help to inform current practice and mentor the broader Open Source Software community. “Juniper have been tremendous support to OSI while we have been establishing the Open Source and Standards Working Group to address the challenges faced understanding open source by the de jure standards community” said Simon Phipps, OSI Director and immediate past President. “Having them additionally offer sponsorship is most welcome and we look forward to further collaboration.”

About Juniper Networks
Juniper Networks simplifies the complexities of networking with products, solutions and services in the cloud era to transform the way we connect, work and live. We remove the traditional constraints of networking to enable our customers and partners to deliver automated, scalable and secure networks that connect the world. Additional information can be found at Juniper Networks (www.juniper.net) or connect with Juniper on Twitter, LinkedIn and Facebook. Discover more about Juniper Networks and open source, at https://www.juniper.net/us/en/company/open-source/.

About The Open Source Initiative
Founded in 1998, The Open Source Initiative 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 public charity with global vision based in California. For more information about the OSI and sponsorship opportunities, please see, https://opensource.org/sponsors, or connect via Twitter.

 

Categories: FLOSS Research

On Why OpenStack Foundation Joined the OSI

Wed, 2019-07-03 12:35

Over the past year, the definition of open source has been challenged, as some companies wanted to change the licensing of their software while continuing to reap the benefits of calling it open source, or at least the benefits of being potentially confused with open source.

That makes the work of the Open Source Initiative more important than ever. For more than 20 years, the OSI has been a steadfast guardian of the Open Source Definition. They’ve kept it focused on user freedoms, evaluating new proposed software licenses against that definition, while discouraging further license proliferation. They’ve also been instrumental to the success of open source through their tireless advocacy and education work.

These objectives resonate with the work we do at the OpenStack Foundation (OSF). Today open source is necessary, but not sufficient: users of open-source licensed software are sometimes denied some of the original free and open source software benefits. We need to go beyond how the software is licensed and drive new standards on how open source should be built. Users should be able to tell easily the difference between a truly open collaboration guaranteeing all of open source benefits and single-vendor or open core projects.

“Without this single, standard definition of [the kilogram] or other fundamental units, commerce as we know it would not be possible. There is no trust in a world where anyone can invent their own definition for units, items, and concepts on which others rely, and without trust there is no community, no collaboration, and no cultural or technological development,” OSI, affirmation of open source definition.

This work cannot happen unless we base it on a strong and steady open source definition, focused on user freedoms. That’s why two months ago the OpenStack Foundation joined other open source organizations in signing the affirmation of the open source definition. That’s also why today the OSF is joining the Open Source Initiative as an affiliate member.

I’m looking forward to working closer with the OSI on those critical topics, and discuss challenges in the future of Open Source with them.

About the author

Thierry Carrez is the vice-president of engineering at OSI Affiliate OpenStack Foundation and an OpenStack Technical Committee elected member. A long-time advocate of free and open source software and Python Software Foundation fellow, he was previously involved with Ubuntu server and Gentoo Linux security.

Image credit: "CarrezBlog.png" is a derivative of "Locusts and wild flowers", by Jonathan O'Donnell , via Flickr, and used with permission under the Creative Commons Attribution 2.0 Generic (CC BY 2.0) license.

This article was originally published in Superuser

Categories: FLOSS Research

Open Source Initiative Welcomes TODO Group as Affiliate Member

Mon, 2019-07-01 12:14

PALO ALTO, Calif. - July 2, 2019 -- The Open Source Initiative ® (OSI), the non-profit corporation with global scope formed to educate about and advocate for the benefits of open source and to build bridges among different constituencies in the open source community, announced today the affiliate membership of TODO Group. Boasting membership from some of today's most active corporations working in and with Open Source Software, the TODO Group shares experiences, develops best practices, and collaborates around common tooling to address some of the most common challenges related to open source program management, development, deployment, and management.

As Open Source Software continues its growth into and across corporate infrastructure, more and more companies are seeking peers and partners to help understand, not only "the value of open source" but "the open source ethos" as well. Businesses across industries--not just technology--use, contribute to, and maintain, thousands of open source projects, both large and small. Despite open source's twenty year history, many of these programs face challenges in ensuring high-quality and frequent releases, engaging with developer communities, and contributing back to other projects effectively. Here, as a resource to those seeking authentic engagement with open source communities of practice, the OSI and TODO Group will work together, helping organizations identify potential projects, assess community alignment, and participate credibly and reliably to foster success.

"TODO Group wants to join as an affiliate to support the mission of the OSI which we believe is a critical organization protecting the values of the open source community." says TODO Group co-founder, Chris Aniszczyk

Of particular note are, The Open Source Guides, developed by the TODO Group in collaboration with The Linux Foundation (also an OSI Affiliate Member), and the larger open source community. The Guides collect best practices from the leading companies engaged in open source development, and aim to help organizations successfully implement and run an open source program office. The OSI and TODO Group expect these guides to be living documents that evolve via community contributions. The TODO Group also runs the official open source program management survey every year.

"OSI is excited about the work TODO Group is doing, especially with its guides. They're paving the way for companies to more fully realize the value of Open Source Software, both for the business and for the end user," said OSI Vice President, Josh Simmons.

The OSI Affiliate Member Program is available at no-cost to nonprofits, educational institutions, and government agencies that support the OSI's mission to promote and protect open source software. As the steward of the Open Source Definition certifying Open Source Software Licenses, by establishing such certification as the standard for open source software development and distribution, and with the support of our Affiliate Membership, the OSI has become a cornerstone of software freedom.

About TODO Group
TODO: talk openly, develop openly. The TODO Group members believe they will improve their open source programs - and their contributions to the open source movement as a whole - by working together. TODO is specifically intended as a forum for companies' open source program managers to come together. Members generally tend to represent companies who consider open source to be an adjunct their core business. To learn more about the TODO Group, visit, todogroup.org.

About The Open Source Initiative
Founded in 1998, The Open Source Initiative 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 public charity with global vision based in California. For more information about the OSI, please see, opensource.org.

Categories: FLOSS Research

Publication of Research on Company Contributions to OSS Projects

Sun, 2019-06-30 16:25

IEEE Transactions on Software Engineering has published an article on company contributions to community open source projects authored by partners in the LIM-IT project.

"On Company Contributions to Community OSS Projects" reports an investigation of how practitioners working for businesses interact with eight community OSS projects of various sizes in diverse domains, including cloud computing and the internet of things. The article also investigates why contributors working for companies use particular ways of working to achieve the strategic aims of the businesses that commission their work.

Through analysis of interviews with practitioners, the article provides insights into how individuals working on behalf of companies can and do interact with projects, and the motivations for their actions arising from business and technical pressures. Factors influencing contributor work practices can be complex and are often dynamic and include considerations such as company and project structure, as well as technical concerns and business strategies.

For example, interviewees reported the value of using mailing list questions to send signals to multiple audiences, including the core developers and their own clients. Other interviewees described the challenges of delivering business products and services that depend on software from the OSS projects investigated, and how those challenges can motivate approaches to the company's software development process that may involve additional work in the short term, but are expected to bring long-term benefits to the business.

The article also describes the motivations of some businesses that contribute to OSS projects in ways that intended to support the project itself rather than just making technical contributions such as implementing new features and fixing bugs. In most such cases, interviewees reported that the OSS project was a significant component of a company product, and, in a few cases, critical to the business. Company contributions aimed at sustaining the OSS project, often made through core developers employed by the business, included nurturing new contributors and improving software quality, and have the benefit of supporting the long term aims of the business.

The article is published as open access.

The LIM-IT Project
The LIM-IT project is a collaborative research project between eight Swedish companies and the Software Systems Research Group at the University of Skövde. The project is financially supported by the Swedish Knowledge Foundation. The overarching goal of LIM-IT is to develop, use, and scrutinise effective work practices and strategies for the development, procurement, and organisational implementation of software systems in a number of complex application domains, where such software systems with associated digital assets typically involve several open source projects (as well as proprietary software).

Submitted by,
Simon Butler, School of Informatics, University of Skövde, Sweden
Björn Lundell, Software Systems Research Group, University of Skövde, Sweden & OSI Affiliate Member, Open Source Sweden

Image credit: "PubCompanyContribsOSSP.png" is a derivative of "BUSINESS_cubestalk.png", via OpenSource.com, and used with permission under a Creative Commons with Attribution (CC-BY-SA) license.

Categories: FLOSS Research

OpenStack Foundation Joins Open Source Initiative as Affiliate Member

Wed, 2019-06-26 21:12

Membership affirms open source community's support of the Open Source Definition and OSI's mission as steward.

PALO ALTO, Calif. - June 26, 2019 -- The Open Source Initiative ® (OSI), steward of the Open Source Definition and internationally recognized body for approving Open Source Software licenses, today announces the affiliate membership of The OpenStack Foundation (OSF).

Since 2012, the OSF has been the home for the OpenStack cloud software project, working to promote the global development, distribution and adoption of open infrastructure. Today, with five active projects and more than 100,000 community members from 187 countries, the OSF is recognized across industries as both a leader in open source development and an exemplar in open source practices.

The affiliate membership provides both organizations a unique opportunity to work together to identify and share resources that foster community and facilitate collaboration to support the awareness and integration of open source technologies. While Open Source Software is now embraced and often touted by organizations large and small, for many just engaging with the community—and even some longtime participants—challenges remain. Community-based support and resources remain vital, ensuring those new to the ecosystem understand the norms and expectations, while those seeking to differentiate themselves remain authentically engaged. The combined efforts of the OSI and the OSF will compliment one another and contribute to these efforts.

"For more than 20 years, the Open Source Initiative has been instrumental to the success of open source through their tireless advocacy and education work, and as the steadfast guardian of the Open Source Definition: focused on user freedoms, evaluating new proposed software licenses against that definition, while discouraging further license proliferation," said OSF VP of Engineering, Thierry Carrez.

"The broad support of our work in promoting and protecting Open Source Software and the specific endorsement of the Open Source Definition is critical for not only the OSI as an organization, but also for the users, developers, and communities who rely on a common set of principles and a shared ethos," said OSI General Manager, Patrick Masson. "The OpenStack Foundation's decision to join now as an Affiliate Member, just as we are seeing some try to manipulate community norms, is extremely gratifying and makes a clear statement. We thank them for their voice."

"Over the past year, the definition of open source has been challenged, as some companies wanted to change the licensing of their software while continuing to reap the benefits of calling it open source, or at least the benefits of being potentially confused with open source, Carrez added. "That makes the work of the OSI more important than ever. The objectives of the OSI resonate with the work we do at the OSF. Today open source is necessary, but not sufficient: users of open-source licensed software are sometimes denied some of the original Free and Open Source Software benefits. Users should be able to tell the difference between a truly open collaboration guaranteeing all of open source benefits and single-vendor or open core projects."

The OSI Affiliate Member Program allows any non-profit organization, educational institution, user community, or government agency—unequivocally independent groups with a clear commitment to open source—to join the OSI in support of our 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 Affiliate Member Program was developed to extend the reach of both the OSI and each participating member through community, collaboration, and co-creation. The program provides a platform to identify, communicate, and address issues important to furthering open source awareness and adoption, whether those initiatives are begun by the Affiliate, the OSI, or emerge from the Open Source Software community.

About The OpenStack Foundation
The OpenStack Foundation (OSF) supports the development and adoption of open infrastructure globally, across a community of nearly 100,000 individuals in 190+ countries, by hosting open source projects and communities of practice, including datacenter cloud, edge computing, network functions virtualization (NFV), CI/CD and container infrastructure. To learn more about the OSF, visit: https://osf.dev

About The Open Source Initiative
Founded in 1998, the Open Source Initiative 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 public charity with global vision based in California. For more information about the OSI, please see https://opensource.org.

Categories: FLOSS Research

CAVO encouraged by—and encouraging—state and local governments’ open source elections systems.

Wed, 2019-06-12 10:23

OSI Affiliate Member, California Association of Voting Officials (CAVO) is reporting significant developments to advance the use of Open Source Software within electronic voting systems.

According to CAVO, the PAVE Act, tendered by United States’ senators Ron Wyden of Oregon and Kamala Harris of California, includes provisions to address financial barriers that could be incurred by state and local governments evaluating open source options for their elections systems.

CAVO communications director Brent Turner explained, the PAVE bill sets a variety of cybersecurity standards, and requires every voting machine used by a state or local government to undergo testing to affirm those requirements are met. In addition to the standards set forth in PAVE, The Department of Homeland Security (DHS) also has their own requirements. PAVE directs DHS to undertake this testing, of both the standards included in PAVE and their own, on behalf of the state or local government.

Turner added, “Local and state governments are of course also free to set their own additional cybersecurity standards for voting machines used in their jurisdictions beyond those identified in PAVE and by DHS”. Section 2216 of the PAVE bill states that DHS will cover the costs to test any open source technology against state or local voting standards. Turner noted this is critical for the adoption of open source options as “proprietary providers of voting technology can easily foot the bill themselves to have their product tested for compliance with those state or local standards, but open source projects may not have the resources to fund the certification process, thus eliminating themselves from consideration by state and local jurisdictions.”

“In essence, the PAVE bill makes it easier for state and local governments to use open source technology, or, at least, to make sure the cost of certification doesn’t get in the way.”

Open source voting pioneers Brian Fox and Alan Dechert have been working on open source solutions since Dechert’s first public demonstration of an open source election system in 2004. Congresswoman Tulsi Gabbard, representing the 2nd District of Hawaii, was the first to include Open Source Software in federal legislation (H.R.5147), what Fox said at the time would, “give appropriate security direction to the nation's election officials. Congresswoman Gabbard is appreciated as a pioneer advocating the science of protecting our democracy."

CAVO expects such federal legislation to help expedite the development of open source voting systems in California, which can then serve as a model for other states. Turner emphasized, “We have been working on this for almost 20 years. We must now make sure that California Governor Newsom and Secretary of State Padilla understand that if we are to have safe and secure elections in the United States, we must immediately transition from the proprietary software model to a GPL licensed open source system.”

The state of New Hampshire, the city of San Francisco, and the United States' largest voting jurisdiction, Los Angeles, recently announced their intentions to deploy open source voting systems. In addition, the California Assembly recently passed CA AB 1784, which provides "matching funds" for counties developing open source voting systems. The bill, according to CAVO, is expected to make it through the Senate and be presented to Governor Newsom for signature.

Categories: FLOSS Research

Knowage Renews Sponsorship in Support of Open Source and Open Source Initiative

Thu, 2019-06-06 10:46

Open Source Software project cultivates collaboration by extending outreach to OSI as part of broader community development.

Knowage, the open source suite for modern Business Analytics, combining traditional and big data sources into valuable and meaningful information, has renewed their sponsorship of the the Open Source Initiative® (OSI).  Knowage (formerly SpagoBI) has a 14-years history of open source collaboration, where individuals and companies work together to meet the latest analytical needs, including collaboration with current OSI Affiliate Members Eclipse Foundation, OW2, and Engineering Group- one of the world's leading specialist providers of services, software development and digital platforms that support both public and private companies or organizations through digital transformation.

Powered by a strong international open source community, and released under AGPL3, Knowage code is freely accessible on GitHub.

For over twenty years, the OSI has worked to raise awareness and adoption of Open Source Software, and build bridges between communities. Support from organizations like Knowage, not only provides the OSI with critical financial resources for continued operations, but even more valuably, extends the OSI's network exponentially through Knowage Labs' multiple international partners and collaborators.

"Knowage proudly supports the OSI's efforts in promoting open source to drive innovation, and shares their goal of promoting growth and contributions through authentic engagement across international communities," said Grazia Cazzin, Knowage Director.

"Knowage highlights how businesses, foundations, and projects can come together to co-create innovative open source software and healthy communities," said Patrick Masson, General Manager of the Open Source Initiative. "Maintaining an open ethos that ensures community success, not just one project's, is exactly how open source should work, and we thank Knowage for their commitment."

As a non-profit, community-driven organization, the OSI relies on the support of volunteers who lend their time to develop and manage internal operations and working groups; individual contributing members, whose annual dues provide critical support and whose votes elect the Board; Affiliate Members, composed of a who's who of open source projects and foundations, and; corporations who choose to support our mission through in-kind donations and generous financial contributions.

About Knowage Labs
Knowage Labs, together with the open source community, develop Knowage Business Analytics software, manage related professional services, and coordinate a network of international affiliates that serve as local contact points for customers and integrators. Knowage Labs professionals are employed by Engineering Group with offices in Italy (Bologna, Milan, Rome, Padua, Turin) and Republic of Serbia (Belgrade). For more information, see the Knowage Community Edition.

About 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 public charity with global vision based in California. For more information about the OSI, please see https://opensource.org.

Categories: FLOSS Research

May 2019 License-Review Summary

Mon, 2019-06-03 18:21

In May, the License-Review mailing list saw extensive debate on the Cryptographic Autonomy License. The list also discussed a BSD variant used by the Lawrence Berkeley National Laboratory, and the Master-Console license.

The corresponding License-Discuss summary is online at https://opensource.org/LicenseDiscuss052019 and covers an announcement regarding the role of the License-Review list, discussion on the comprehensiveness of the approved license list, and other topics.

Cryptographic Autonomy License

The review of the Cryptographic Autonomy License (CAL) continues. Back in April, Van Lindberg submitted the CAL as a network copyleft license, but with broader scope than the AGPL (see the summary).

While the CAL clearly tries to comply with the OSD, there are widespread concerns as to whether some fundamental aspects are compatible with open source and software freedom.

Public Performance

Bruce Perens claims that use of public performance rights implies a field-specific restriction in the sense of OSD #6, e.g. because it would allow private use but not public use. (Note: the mere use of these rights does not create such a restriction.)

Scott Peterson [1,2] argues that software interoperation cannot be a “performance” in the sense of US copyright law – even if a public performance right exists for software. The CAL makes software interoperation more difficult and should not be approved. Van Lindberg provides his analysis of the term. Notably, Lindberg's definition does not require a human audience for the performance.

Chestek [1,2] finds a potential problem with how public performance interacts with modified works, as parts of the license only consider public performance of interfaces. Van Lindberg appreciates this point.

User Data

Bruce Perens argues that the CAL's user data provisions go beyond copyright law. Users don't have an a priori right to receive their user data until the CAL created this right. But this means that the operator's copyright license is conditional on fulfilling the user data obligations, which is an unreasonably far-reaching compulsion.

Pamela Chestek follows up on April's discussion on whether the CAL's user data clause is comparable with the GPLv3's anti-Tivoization clause. Van Lindberg sees a distinction between two of CAL's clauses: The CAL forbids locking down the software via cryptographic means, a kind of Tivoization. The CAL also requires user data to be provided, which is necessary to ensure user freedom in a SaaS context. Bruce Perens agrees that this should be fixed – but by some law, not by a license. And anyway, the user should just keep backups of their data.

Nigel Tzeng [1,2,3] thinks the user data obligations are unrealistic and excessive, for example where the operator has no easy way to make a copy of the data. This is problematic even with a good faith effort to comply, and makes the CAL “unworkable for most operators.” How detailed do requests have to be? Does holding a copyright license imply a possessory interest? But if the user data only covers the user's inputs (not modified or intermediate formats), the right to a copy is also not very useful.

Van Lindberg [1,2,3] responds that the user data clauses ensure data portability to inputs and outputs of the software, and where the user has some possessory interest in the data. What that encompasses precisely would depend on the jurisdiction. Having a (public) license for some data does not imply a possessory interest.

User data requests will typically only cover data that the end user uploaded. This can be implemented via export functionality in the software (note: as is already common in GDPR-compliant systems). That does not imply excessive effort for the operator. Where no such functionality is implemented this may require some effort, but that is comparable with having to provide the source code. When the request covers data that they didn't upload, they would have to specifically demonstrate their possessory interest.

Bruce Perens [1,2] doesn't buy Lindberg's argument that providing user data were easy. In a blockchain setting, providing user data might be as simple as providing a copy of the blockchain. But in other settings operators have no guidance or guarantees. Peer to peer applications seem especially problematic, since every end user would be an operator. Lindberg's fixation on certain SaaS settings is not helpful.

GDPR

Chestek [1,2] assumes the GDPR is being referenced because there would otherwise be a conflict with CAL compliance. Such preferential treatment of the GDPR would be “facially non-compliant with OSD 6”: it relieves someone complying with the GDPR from complying with the CAL. Compliance with the CAL might also be impossible if a jurisdiction has conflicting privacy laws. The section should be rephrased to avoid being specific to any legal regime, or removed when no conflict is expected.

Lindberg [1,2,3] explains that the reference to GDPR is intended to streamline compliance: if the operator already complies with the GDPR, that's already good enough for compliance with the CAL's user data requirements. This is just an interpretive guide, and doesn't confer special permissions. Given the amount of confusion that clause has caused, Lindberg considers removing it.

Fontana: The CAL is not Free because it encumbers APIs

In April, Pamela Chestek had asked why specifically the CAL should not be approved, under the assumption that public performance rights are a thing for APIs.

Richard Fontana responds:

  • it forces reimplementations of a CAL-covered API to be open source
  • Joke: any license can be opposed on the grounds that it violates OSD 5/6 (restricts some persons, or fields of endeavour)
  • but here the CAL really looks like such a violation
  • not necessarily a problem: even the GPL certainly restricts some persons
  • “From a software freedom perspective, extending a copyleft requirement to an interfae is unjust.”
  • CAL might violate the spirit of OSD 9 (don't restrict other software), similar to the SSPL.
  • OSI review should not just check OSD conformance, but also whether the license provides software freedom
  • the CAL's unreasonable burden on interface re-implementors violates software freedom.

  • that the license limits itself to copyright law doesn't mean it provides software freedom

  • a copyleft license like the CAL doesn't necessarily make more software available under open licenses.

    • unusual license might see no adoption
    • seems to serve a proprietary dual-licensing business model
    • which would mean it would actually result in less open software
  • questions what it means to publicly perform an API.

    • could see such a performance for GUIs
    • but APIs are not typically perceived by users

Pamela Chestek responds that she still can't see the CAL “as even slightly different from the GPL in reach”, under the assumption that API copyright exists. Chestek is more concerned about the applicability of public performance rights outside the US. Chestek is confused by Fontana's position that a free software license may not apply copyleft to all aspects of copyright (such as API copyright).

Chestek does not believe Fontana's argument that the CAL will result in less free software. If some copyleft licenses are harmful, where exactly is the tipping point? Why is AGPL acceptable but CAL not?

Fontana responds that a license may decide to cover API copyright, but no FOSS license should do so. Fontana thinks that the CAL breaks with the (A)GPL tradition, and is confident that the FSF would condemn any interpretation that the CAL were essentially the same as the GPL.

Perens: Licenses should not cover API copyright

Bruce Perens summarizes his stance on free software:

  • since the DFSG, it has been clear that running open source software for any purpose must be allowed
  • it is necessary that the rules don't have total sympathy for proprietary developers
  • it is fine to require the sharing of modifications
  • many network copyleft licenses change the fundamental deal of open source
    • running for any purpose no longer allowed
    • such licenses no longer respect users
  • approving network copyleft licenses is a slippery slope towards losing authority
  • supporting API copyright is a bad idea because it can be used against the open source community
    • perhaps later API copyright licenses will become necessary as a defense

On the interpretation of the OSD, Perens sees two ways forward: Either the OSD is interpreted literally, but is also amended/clarified regularly. Or, the OSD is interpreted intelligently.

Van Lindberg argues that “we have already entered the world in which licenses like the CAL are necessary”: “Put aside the network aspect. How many reimplementations of the GNU readline interface are there? How many bashisms have made it into other shells? Under Oracle v Google, those are derivative works.” Perens disagrees and urges not to “concede the fight before it is lost.”

Henrik Ingo agrees with Perens that the CAL oversteps some boundaries, in particular with its user data requirements. However, the age of SaaS makes strong network copyleft licenses necessary in order to protect end user freedom. Ingo hopes a scaled-down CAL would get approved.

To Peren's point that approving non-free licenses could cause the OSI to lose authority, Ingo adds that failing to approve OSD-compliant licenses would be harmful as well. “Network copyleft is clearly an area where currently supply and demand don't meet”. Perens obviously disagrees and reminds that approval can cause problems for the community. The community is also not reliant on OSI approving new licenses, just like the FSF doesn't have to write new licenses: “While we are starting to see reasons for GPL 4, nobody is in a hurry.”

Pamela Chestek [1,2] questions why involving public performance rights is necessary to protect APIs. “Public performance” is an US-specific term, and the CAL might stretch beyond the bounds of copyright. In contrast, the GPLv3 defines its term “propagate” in terms of copyright law. Chestek suggests the CAL could borrow this approach. Lindberg doesn't quite disagree, but objects on multiple points. The CAL should make its intention to cover public performance explicit, it already defines the term within the license, it must also consider IP other than copyright, it doesn't stretch beyond copyright, and Lindberg would like to stick to existing terms.

Freedom in Website and Blockchain Scenarios

Pamela Chestek asks whether she would be eligible to receive a CAL-covered websites source code when she enters a third party's user data into a form on the website. Van Lindberg responds that yes, she would be eligible for the source just as under the AGPL. However, the source code requirement already triggers due to using the software. Here, the third person's personal data is not that third person's user data, but the user data of the one entering the data into the website.

Bruce Perens [1,2] extends the scenario with a blockchain-based example, where there might be “derivative data”. Perens also thinks the CAL's definition of source code includes private keys that were used to manipulate data in the blockchain. After all, any blockchain participant would be an operator processing user data. (Note: this may be a misunderstanding of both blockchain technology and the CAL.)

Van Lindberg [1,2] provides two detailed replies. The CAL does not have a concept of derived data. Instead, obligations arise if someone is a Recipient in the sense of the license. The operator's obligation to provide data only extends to the user's data, and only to the extent that the operator can retrieve this data. Disclosure of private keys is not required in the context of user data, although it could be required in the context of the source code as part of the CAL's anti-Tivoization clause. In general, Perens's hypotheticals “don't really make sense”, and would result in roughly the same outcomes as under the AGPL.

Bruce Perens [1,2] claims that while the CAL may or may not violate the OSD, it definitely violates the FSF's Freedom Zero “to run the program as you wish, for any purpose”. The problematic user data terms even apply to unmodified software. In Peren's eyes, Lindberg has arbitrarily redefined the FSF's concept of Software Freedom to cover user data. Lindberg [1,2] insists the CAL ensures end user freedom the same way the GPL does, this involves preventing intermediaries/operators from taking rights away. The question to decide is precisely whether the operator's freedom to lock down end user data is more important than the end user's freedom to run the software with their own data. Lindberg and Perens just disagree on how to resolve that dilemma. Lindberg has also asked the FSF for their opinion.

Bruce Perens [1] also thinks the user data terms are unnecessary in the decentralized context for which the license was drafted. Lindberg argues that the CAL helps to keep a system decentralized.

Bruce Perens [1] sees an overarching problem with the license: that even competent attorneys seem to be struggling with its terms, particularly regarding user data and public performance. Courts might not share Lindberg's interpretation. Developers without legal counsel don't have the “slightest hope” of applying the license correctly. Lindberg [1,2] concedes that fully understanding a legal instrument like the CAL does require counsel. But the CAL is no more complex than the GPL. The effect of the CAL can be summarized concisely in a manner that would be understood by an ordinary developer. Perens [[1]perens:cal:competent2,[2]perens:cal:gpl-simple] [Perens]perens:cal:competent2 disagrees with that summary, and thinks Lindberg's stance is deeply unsympathetic to users.

Other Points

Re claim by Pamela Chestek: OSI decision making is unpredictable. Bruce Perens responds that “we like it that way”. OSI review should not mechanically implement pseudo-laws, but care about the community's interest.

Bruce Perens asks whether the copyright holder would also be bound by the conditions of the CAL, e.g. regarding user data. Peren's understanding is that they would not be bound, which would privilege them compared to other operators. Van Lindberg claims that the CAL places no party in a privileged position.

Van Lindberg argues that the CAL is also necessarily because the AGPL is so unclear and ambiguous. The CAL would be clearer, and would have applicable case law “at least by analogy”.

Kevin Fleming asks if the CAL is only fully effective if patents are involved. Lindberg responds that patents holders will have extra tools, but that the CAL is based equally on copyright, patents, and contract methods.

Pamela Chestek and Van Lindberg continue their review discussion from last month.

  • Lindberg updated language around the LGPL/MPL-style Combined Works exception.

  • Chestek thinks the anti-DRM clause is “unintelligible”. Lindberg provides a side by side comparison of the clauses in GPLv3 and CAL.

  • Chestek thinks the CAL is overly complicated when trying to ensure that all permissions are passed to downstream recipients. Isn't this as simple as “cannot impose additional restrictions”? Lindberg responds that this isn't as simple. He doesn't want to enumerate allowed restrictions like the GPL does. However, Lindberg updates relevant language in the CAL.

Henrik Ingo is torn on whether the CAL should be approved. Prima facie, the CAL violates the OSD – but only due to its well-justified, tightly-scoped user data requirements that are necessary to ensure end user freedom in practice: “the CAL is a net positive contribution to software freedom.” The user data clauses do not violate Freedom Zero if the operator is viewed as merely running the software on behalf of the end user. If this violates the OSD, maybe the OSD should be amended.

Bruce Perens [1,2] doesn't think the OSD can be a comprehensive list of allowed or disallowed license features. It should not be amended until it can be interpreted mechanically.

Ingo had invoked the License Zero review as precedent. Richard Fontana clarifies that L0 was retracted and not rejected, but that the significant past “hostile receptions” should be treated with some significance.

Lindberg's Summary

Van Lindberg [1,2] tries to summarize various objections and discussion points, and provides references to various arguments that have been made. The three main issues are:

  1. whether data portability can be guaranteed as part of software freedom and under the OSD
  2. whether public performance is effective, OSD-compliant, and good policy
  3. whether the CAL is too complicated or unclear

The objections mainly apply to the operator of the software, not to end users. Issues 1 and 2 are fundamental policy questions.

Bruce Perens confirms he believes that “an operator's ability to lock down the data they receive from end users is core to the OSD and to the concept of Free Software” (as phrased by Lindberg). John Cowan thinks Lindberg is approaching this from the wrong end: the right to commit crimes is not core to FOSS. But using FOSS licensing to enforce ethical actions is a Very Bad Idea.

Lawrence Rosen [1,2,3,4] is against approval. While Rosen accepts a public performance right for software (his own OSL uses it), it has limited value and has nothing to do with normal execution of the software. Performance does not include the rendering, display, or execution of a software. Rosen thinks the CAL's user data clauses are troubling, since data is not copyrightable. At most, a confidentiality clause would be appropriate. Lindberg [1,2,3] points out that the CAL has nothing to do with copyrightability of data, and uses a multi-pronged mechanism of which copyright is only one part. Lindberg thinks Rosen is reading the definition of public performance in US law too narrowly, and provides caselaw to bolster his argument.

Luis Villa argues that the CAL is not excessively complex. The CAL and GPL use similarly complex language, although both are more complex than other licenses. If objections on the grounds of complexity were to carry any weight, then “OSI can... only approve long-existing licenses (or trivial permissives). (If that's the board's intent I'd love to hear it; we can all unsubscribe from this list and call it a day!)” McCoy Smith concurs: there's a difference between ambiguity (bad) and inherent complexity (acceptable) of a license.

Pamela Chestek adds the major objection that the CAL would be the first open source license to encumber API reimplementations. This is the main issue, compared to any debates over public performance. Henrik Ingo argues that both are problematic, and that invoking public performance rights seems unnecessary except for the CAL's goal to implement API-copyleft. Lindberg views these issues as independent. The CAL's use of public performance is primarily an alternative to the AGPL's “network interaction” mechanism. API copyleft is a reaction to the Oracle vs Google case.

Richard Fontana thinks Lindberg's summary fails to accurately capture fundamental objections. The issue is not whether API copyleft could be premature, the whole concept runs against FOSS and industry conventions. If a license makes use of API copyright, then please only for maximally permissive licensing. Henrik Ingo thinks API copyright would be a huge detriment to the industry – would any readline implementation be copyright infringement? But if it happens, the FOSS community shouldn't just cede that ground. “Still, as long as we're not there yet, we of course shouldn't be the first party to strike.”

LBNL BSD

Sebastian Ainslie [1,2,3] asks for legacy approval of the LBNL-BSD, a 3-clause BSD variant used at the Lawrence Berkeley National Laboratory (LBNL). Compared to the common BSD template, it adds a caveat that U.S. Dept. of Energy approval may be required, presumably required for all DOE labs. It also adds a paragraph that published modifications fall under the same license by default. This is a bit like an implied CLA, or like copyleft with an opt-out. Ainslie explains this is necessary in order to accept contributions without signed CLAs.

Legacy approval

There is some contention on what legacy approval signifies.

Bruce Perens raises a license proliferation objection. McCoy Smith wonders why OSI approval is needed if the license has already been used for over a decade. Richard Fontana wonders whether actively used licenses are eligible for legacy approval. Kevin Fleming assumes that the use of legacy-approved licenses would be discouraged. On further reading, Fontana finds that legacy approval is just retroactive. It does not require the license to be unused, and does not imply any discouragement.

Richard Fontana [1,2] thinks that legacy-approval must generally meet the same standard as new licenses, especially with regard to OSD conformance. But it would be a good idea for OSI to take a more active role to explicitly approve licenses that are commonly used in Linux distributions. Legacy approval should therefore be more lenient about sloppy or amateurish drafting. 15 or 30 years ago, licenses simply were not drafted with the same standards we expect today.

Fontana sees many people who do not accept OSI's stewardship of the Open Source definition. They can point to a vast collection of open source software that does not use OSI-approved licenses. A mass effort to approve more obviously-FOSS licenses would then have some benefit.

Actual review

Fontana sees the added paragraph as unclear or sloppily drafted. It might not trigger the default license if modified versions are privately given to third parties, without these modifications being published. This is different from Apache 2 which just codifies the “inbound = outbound” expectation. Pamela Chestek [1,2] wonders whether the paragraph is even relevant: “inbound = outbound” is the default expectation, with or without that paragraph. The paragraph mainly affirms that modifications can be published under a different license. Henrik Ingo shares this view (see also below). John Cowan disagrees: by default the modifications would have no license, as the BSD would only apply to the original work.

Tom Callaway questions why the paragraph seems to assign different terms to enhancements than the main BSD license. Richard Fontana too thinks that the contributor license is broader than the BSD. Ainslie [1,2] argues that no such different terms are used, but this seems to confuse the submitted license with a suggested simplification by Callaway.

McCoy Smith and Henrik Ingo note that OSI usually rejects licenses that give preferential treatment to one party, or are specific to some entity. Here, this is not a problem: while the LBNL is mentioned explicitly as a recipient, it receives the same rights as the public.

Henrik Ingo is slightly concerned about the default license paragraph acting like an implicit contributor agreement. But this is not a problem in practice: code added to a BSD-licensed project is considered to be BSD-licensed as well. The paragraph only seems like a clarification in case of a standalone patch is sent without explicit license indicators.

Brendan Hickey isn't sure whether implicit “inbound = outbound” should be promoted. Hickey points to projects like Linux that expects patches to be explicitly signed off by the contributor. Hickey also points to the C-FSL review, where it was discussed that licenses cannot do copyright assignment. So what kind of licensing terms would actually be necessary in order to safely accept contributions? Henrik Ingo responds that the license status of published modified versions is usually clear without having to take extra steps, and that no copyright assignment is involved.

Richard Fontana suggests a DCO (https://developercertificate.org/) as a simpler way to ensure that contributions are properly licensed.

Ainslie says that DOE labs cannot use a vanilla BSD license, which made small changes to the license necessary. Pamela Chestek [[1]chestek:lbnl:doe,[2]chestek:lbnl:doe2] [Pamela Chestek]chestek:lbnl:doe asks for documents that require these changes and McCoy Smith asks which specific changes are mandated. Ainslie says they have to attribute their funding source and add a notice that DOE approval be required. McCoy Smith questions whether the addition of a notice even creates a new license. It is unclear to Chestek which of these changes are part of the license that is under review.

McCoy Smith [1,2] thinks making the license conditional on DOE approval could be an OSD 7 issue. But is that a license condition, or just a notice?

Pamela Chestek asks how many projects use this LBNL license. Ainslie says it's used by nearly all open source software from Berkeley Lab, adding up to hundreds of releases.

Master-Console

Wayne Rangel Wayne Rangel [1,2] submits the “Master-Console's Open Source Definitive License” for approval. It is difficult to tell, but the rationale for this license seems to be:

  • that the original author can take down malicious modifications
  • that the source code shall be offered in a specific manner, presumably that the source code can be downloaded via a web browser

Lukas Atkinson expresses their frustration that the license seems impossible to understand, both from a legal perspective and due to the unidiomatic English. Christoper Sean Morrison thinks “that should be grounds for rejection alone.” McCoy Smith sees the license terms as an OSD 5/6 violation. The license is also likely non-free, “although the wording is such that I can’t quite tell.” Bruce Perens points to the Artistic License as an example where an unclearly drafted license resulted in high costs to third parties.

Richard Fontana suggests the license is not yet ready for review. Pamela Chestek [1,2] asks for the license to be retracted from review.

Help Wanted!

Our current editor of the monthly License-Discuss and License-Review reports, Lukas Atkinson, will not be available to continue in June and July, and may have limited availability throughout the rest of the year. If you would like to join the OSI as list editor, or know someone who might, please contact OSI General Manager Patrick Masson. The list editor works on a freelance basis to provide monthly summaries of the License-Review and License-Discuss mailing lists.

Categories: FLOSS Research

May 2019 License-Discuss Summary

Mon, 2019-06-03 18:21

In May, the License-Discuss mailing list talked about:

  • relationship between the License-Review mailing list and the License Comittee
  • evolution of the license review process
  • comprehensiveness of the approved license list
  • licenses of licenses
  • would three licenses be enough?
  • email threading

The corresponding License-Review summary is online at https://opensource.org/LicenseReview052019 and covers extensive debate on the Cryptographic Autonomy License, as well as discussion on a BSD license variant.

License-Review / Committee Relationship

In the review of the CAL, a minor point was whether the review of the License Zero should be characterized as a “rejection”.

Luis Villa talks about the history of the License-Review list, that the list at times was an OSI committee, but that any decision making authority lies solely on the OSI board.

Richard Fontana feels that community engagement in the list has declined, making it more difficult for OSI to argue that review decisions reflect community consensus.

Luis Villa isn't sure that engagement has gone down, but thinks the level of engagement is definitely unhealthy – 100+ email threads chase away potential submitters.

Henrik Ingo likens list participation to jury duty. Ingo also points out that there is no need to chime in to repeat a consensus opinion.

Christopher Sean Morrison agrees with Ingo's point that mailing lists dictate “efficient silence”, without a mechanism to silently signal agreement. But engagement also suffers from “rehashed-topic fatigue”.

Pamela Chestek sees some bullies on the list. Someone may stay silent not out of agreement, but to avoid conflict.

Nigel Tzeng suggests anonymous voting by OSI members. (Note: but that doesn't help with discussions.) Fontana thinks that would be ripe for abuse. Tzeng thinks the current system can also be abused, presumably referencing the NOSA review.

Scott Peterson argues against maximally precise rules, both regarding the review process and possible OSD amendments.

McCoy Smith views the board elections as a kind of indirect vote. Henrik Ingo warns that direct democracy can distort a vote. The OSI board must make decisions on their own responsibility.

Evolving the License Review Process

Pamela Chestek announces the new OSI License Review Committee, consisting of Pamela Chestek (chair), Elana Hashman, Chris Lamb, and Simon Phipps. They recognize the need for improvement of the review process, so that all points of view are represented in the discussion. As a first step, they clarify:

  • License-Review list collects feedback from the public about proposed licenses. The Comittee considers these responses when making their approval recommendation to the OSI board. If a license is not yet ready, a moderator can move discussion to License-Discuss.

  • License-Discuss is for general questions about open source licenses, and for licenses in their early stages of development. It is recommended to develop new licenses in the open, and to regularly seek feedback from License-Discuss.

  • There will be an effort towards better moderation, to ensure appropriate conversation and a good pace of discussion, and to encourage wider participation. This includes rules to limit hostility, frequency, and repetitiveness of messages, includes follow-ups from moderators to unanswered questions, and includes enforcement of the existing Code of Conduct.

  • The website now clarifies the license review process: community consensus is no longer a precondition. Instead, the board takes the community discussion into account for its decision.

Simon Phipps clarifies that Chestek's announcement represents the decision of the OSI board.

Bruce Perens perceives this change as directed squarely against him. “I, and others, have today been ejected from the license committee.” (Note: this assumes the view that the list members are the committee.) Perens does not think the mere number of messages would be a problem – they are necessary to clarify important questions. Perens doesn't see the point in accommodating people who don't (yet) participate on the list.

Chestek disagrees with the characterization that anyone would have been ejected – instead, these changes have the goal of inviting more diverse responses than is currently the case. Chestek points to concrete examples how Peren's messages come across as agressive: “this is a tone and style of engagement that is inappropriate.” Perens feels this rejects his viewpoint without appropriate concern.

Russel McOrmond lauds Perens for being a persistent advocate of software freedom, and urges him to not take push-back personally.

Lawrence Rosen appreciates the clarity of the new process, but thinks there is too much focus on strict codes of conduct. Just delete the emails you don't want. Rosen is also surprised to recently learn that Perens represented the OSI in their open standards activities (Perens responds). It is important that it's clear within discussions who speaks for OSI and who doesn't. Rick Moen concurs, and urges everyone to assume good faith. Moen also makes a distinction between different kinds of mailing list moderation. In a certain sense, the OSI lists are unmoderated.

Perens responds to Rosen's aside about standards engagement. Perens also thinks any accusations of bullying are over the top, and that these changes to the list are just tone policing. Perens cautions that “license submitters will tell the story as it is most advantageous to them”, especially if they are lawyers. It's important to be able to call that out when it happens. John Cowan thinks Peren's point about lawyers is counterfactual. There's a difference between rethoric and outright misrepresentation.

Chestek agrees with Rosen that all opinions should be heard, but these can't be expressed in any way you want. A “deal with it” attitude alienates valuable voices. In contrast: “I've never heard of a forum where people won't participate because it's too polite”. Rosen thinks some blustering is normal for lawyers, and that politeness is not generally necessary: “That is boring. We are adults here.”

James thinks moderation should only be done as last resort and as transparently as possible because it can have chilling effects. John Cowan recalls moderation activity on Fidonet: moderation isn't as large a problem as it might seem, and bans were well-deserved.

Fontana appreciates the improved clarity brought through Chestek's changes. The (purely advisory) role of the License-Review list is a major change of how the process is described, but it reflects the actual process more accurately.

McOrmond thinks the line between passion and rudeness is too subjective to be useful. Strict focus on a CoC would exclude passionate people. Some amount of shared views are necessary in a community. Rick Moen counters: it's perfectly possible to find some common ground and cooperate with people whose views clash. The OSI list “is a natural place for people supportive of OSI's real-world objective.”

There is a bit of a side discussion about threats to and core issues of FOSS by McOrmond [1,2] (Affero etc is a threat), Perens (Affero is fine), Simon Phipps (the rules serve the movement), and Moen (software freedom is a shared value).

Martijn Verburg chimes in with an assessment that OSI's list are more “robust” than others. “An attempt to make both lists more welcome to voices […] can't do any harm.”

Moen suggests a conspiracy theory: that these claims of uncivility arose after the OSI didn't approve certain licenses. Are sinister forces trying to silence effective critics? Would those more diverse views not be more sympathetic to such rejected licenses? (Note: it's impossible to tell to which degree this is joking.) Chestek responds: “I understand that people on this list may be skeptical of my commitment to software freedom and/or open source software”. But the Committee and the Board are more than a single person. “I do hope that simply having a different opinion on the meaning of software freedom at the fringes doesn't mean that one has become captive of anti-freedom forces.” The OSI is working on important problems, such as the function of the lists, the quality of the review process, and the exact scope of open source.

Henrik Ingo writes a detailed response to various points.

  • the review process hinges on the few who can actually dissect the licenses and read all the emails
  • the list seems comparatively disciplined, aside from discussions that rehash long-past reviews
  • the SSPL review saw an influx of new participants. Where there were problems, the list self-regulated
  • that a new board points to the existing CoC shouldn't be news
  • it is more concerning “that the board believes there is an actual issue that needs fixing”
  • some of the “concerns” on the list are just lawyerly bickering or lobbying to change OSI policy
  • in many of the mentioned cases, the reasons for non-approval are perfectly clear and don't have to be relitigated constantly
  • OSI review is not a court, no cases are lost – revised licenses could be approved
  • review is not just about checking whether the OSD applies, but also about how the new license serves the community
  • it is not sufficient that a license does no harm
  • license review is a lot like “code review”, in the sense that there is a kind of shared ownership
  • whereas the FSF's Four Freedoms have significant backing material and discussion, the OSD seems so unanimous and obvious that no comparable body of commentary exists
  • maybe that is a problem, and more commentary would help?
  • the process seems to be working better than ever, so why fix it?

Richard Fontana thinks the review process is perceived as unpredictable because few licenses make it to a board vote. Those that do tend to be obvious cases and don't need a rationale. Most problematic licenses are retracted by the submitter due to community feedback. Fontana also thinks the OSI has a problem dealing with mistakes, such as approved licenses that are not open source under current understanding. A de-listing procedure might be necessary.

Henrik Ingo thinks outright de-listing would be problematic. As a first step the license stewards could be asked for voluntary retirement of the licenses. Otherwise, they could be moved to a “not recommended” category that recognizes that they were used in good faith.

Nigel Tzeng thinks de-listing licenses would be problematic because they would likely target special-purpose licenses. Tzeng is particularly concerned about the (lack of) acceptance of Government Open Source (GOSS) licenses. (Note: due to overwhelming volume and limited novelty, this summary will not cover the ensuing discussion about GOSS.) Regarding possible delisting, Perens states that it is not OSI policy to promote some licenses over others, beyond marking some as “legacy”. Even though in practice, three licenses would be enough (see separate section).

Tzeng doesn't think his perception that the lists are dominated by Perens and Fontana should be treated as an ad-hominem attack. Perens responds that having an assertive personality paired with relevant expertise should be fine Rosen [1,2] disagrees most harshly, Perens wonders how that response can be anything but ad-hominem. Henrik Ingo expresses the meritocratic view that Peren's and Fontana's influence is mostly a consequence of all the time they spend reviewing licenses.

Luis Villa thinks Chestek's clarifications are fantastic, but is concerned that the meaning of “software freedom” is still unclear in an OSI context. Villa notes that while these improvements target the decision-making process, improvements might also be needed for the record-keeping process. The list archives are an unsuitable medium, instead authoritative summaries are needed. Villa provides some links on RFC-like processes. This seems similar to the March 2019 discussion whether a PEP-style process would help.

Comprehensiveness of the Approved License List

Luis Villa argues that the list of OSI-approved licenses isn't a comprehensive list of usable open source licenses. It should therefore be avoided in contracts or license clauses. But if not that, what is the purpose of the list? Would it make sense to create a smaller list of useful licenses? Villa points to his Blue Oak project as a list of useful permissive licenses.

Richard Fontana thinks the approval process is more important than the resulting list. In a way, the licenses are just a medium through which “open source” is clarified. Fontana also warns against relying on self-appointed authorities, and notes that OSI's License-Review is more transparent than alternatives.

Ben Hilburn [1,2] thinks this discussion is important, but finds Fontana's standpoint confusing. Whether a license is “open source” is defined by its OSI approval. Otherwise, how could OSI be an arbiter of that term?

Nicholas Weinstock insists that the OSD and not the review process is the definition of open source. It follows that the OSD is not just a bunch of factors to consider during review. It also follows that licenses can be open source without being OSI-approved. Too much focus on the list of currently approved license would also result in a weird status for legacy licenses that have since been removed from the list.

Van Lindberg likens OSI approval to a product certification. It doesn't matter whether something is potentially approvable, only whether it has been approved. In the end, it must be OSI's call to decide whether a license satisfies the OSD. In contrast, the term “Free Software” could be used more freely. Nicholas Weinstock disagrees with Lindberg's comparison: OSI approval is not a completely neutral review, but takes wider concerns into account.

Lindberg argues that only OSI-approved parts of a Linux distro should be called “open source”. There needs to be some definition of that term, and clearly it is for the OSI to decide what it means.

McCoy Smith [1,2] links to OSI's deprecation/retirement category (https://opensource.org/licenses/category) which “should not be used to license any new code.” Lindberg [1,2] claims that it is not clear whether such licenses still are open source. Lindberg suggests a cut-off date.

John Cowan argues that “law is whatever the judge says”, here: open source is whatever the OSI says. It is then perfectly fine to refer to the list of OSI-approved licenses. It is just that this view provides no guidance for OSI's review process. This approach works fine as long as OSI's decisions do not deviate too far from community expectations.

Stephen Paul Weber occasionally sees such “any OSI-approved license” terms in contests or in aggregators. Sometimes, any OSI- or FSF-approved license is allowed, to avoid choosing “sides”. Fontana thinks that approach is clever: both OSI and FSF are respected neutral authorities, unlike e.g. Blue Oak or Fedora. As a historical point, Fontana remembers that Fedora did not rely on the OSI license list because OSI was then seen as too commercially influenced. Nowadays, OSI criticism seems to be the opposite. Henrik Ingo thinks the OSI is now much more important than back then, because Linux distros no longer have the role of kingmakers: whether the software is packaged for Debian or Fedora is no longer crucial for an open source project.

Ingo doesn't think the OSI license list should even try to be comprehensive. Most open source software is covered by a handfull of licenses, but there is a long tail of presumably-compliant licenses. Those can be approved when they are submitted, but there's no need to actively seek them out. Fontana does see some value in mass legacy approval: licenses without OSI approval are common in Linux packages. Approval would defuse the claim that these weren't open source. Ingo thinks distros have different motivations than the OSI. For example, the OSI did not approve the libpng license – but Linux distros will continue to ship it.

CC0 and Patents

Weinstock had mentioned the failure to approve CC0 even though it was OSD-compliant. Fontana interjects here: there are grave concerns because it explicitly does not license patents. Nigel Tzeng [1,2] retells the history of 2012 CC0 review, claiming that it was not as simple as Fontana purports. The CC0 is now a widely used open source license, despite not being OSI-approved. In contrast, Henrik Ingo and Rick Moen recall that Fontana's concerns were a quickly growing consensus. Fontana goes into more depth about his motivations at the time. The CC0 review helped build an understanding of the issues around patents in open source.

Christopher Sean Morrison thinks the problem is that the OSI has no clear policy on the role of patents. If patents are involved, a licenses that excludes them arguably violates OSD 7. But without patents, such a license would be still OSD-compliant. (Note: but compare also Fontana's message referenced above.)

With regard to the role of patents, Rick Moen [1,2,3] argues that having an open source license is a necessary but not sufficient precondition for a software actually being open source. As a hypothetical, Moen considers a jurisdiction that somehow encumbers a BSD-licensed software.

John Cowan [1,2] disagrees with the premise of Moen's hypotheticals. The biggest patent threat to open source software is not from authors but from third parties. It isn't possible to conclusively determine whether some software is safely open-source. Rick Moen doesn't think that stance is workable. Open source software should be called open source, until the day that the software is encumbered by a concrete threat.

Nicholas Weinstock agrees with Cowan's analysis. But it would be useful to discuss open sourceness of licenses separately from the licensed programs. The OSD does not make such a distinction consistently.

Van Lindberg argues that open source only describes the licensor–recipient relationship. Third parties are out of scope, and no warranties about this are given by the license. Moen agrees, but this doesn't change the issue that software cannot be distributed freely if there are claims against it by a third party.

Lawrence Rosen notes that some licenses have defensive termination clauses that may be a sufficient defense against third party patent threats. (Note: Apache 2 and GPLv3 have such clauses.) Bruce Perens is concerned that such clauses could be ineffective if a company moves the patents to a separate entity.

The GPLv2 includes a “freedom or death” clause that can prohibit distribution in certain jurisdictions. Fontana is of the opinion that software ceases to be open source if this clause is invoked.

As an aside about the BSD, Lawrence Rosen suggests it's the OSI's responsibility to warn the public that BSD is not a useful license due to its lack of a patent license – “Use a professional license instead!” Morrison thinks that is baseless fear-mongering. Has this risk actually been tested? McCoy Smith doesn't recall caselaw, but links to academic literature.

License Licenses

Patrick Masson wants to update the OSI license list to include metadata about the license, such as the license of the license text.

Thorsten Glaser provides metadata for his MirBSD license, but notes that no license for it's text has been adapted.

John Cowan links to/extracts the relevant licensing information from GPL, EPL, Apache 2, MPL 2, CDDL and points out that MIT/BSD are freely modified in practice. Lawrence Rosen extracts the relevant paragraph from the OSL.

Richard Fontana cautions that the license submitter and the copyright holder can be distinct, and that noting a copyright holder is not always useful. E.g. the MIT license has no copyright owner, no license steward, and isn't even affiliated with the MIT. (McCoy Smith links to some MIT archeology). It is also questionable whether licenses are copyrighted in general. (Perens concurs). In contrast, Pamela Chestek provides precedent in favour of copyrightability for legal documents. “To those of us who write them, they are as creative as code.”

Three Licenses

How many licenses does one actually need?

Bruce Perens Bruce Perens [1,2] suggests that three licenses should be enough for anyone: AGPLv3, LGPLv3, and Apache 2. They are mutually compatible, OSI and FSF approved, have explicit patent terms, and cover a wide range of license goals from permissive to network-copyleft. Why not guide people towards this “strategically coherent” set?

John Cowan answers: because that would look like ASF/FSF favoritism.

Brian Behlendorf agrees that dealing with dozens of subtly different licenses is tiring. But OSI's legitimacy derives from its principles. Favoring some licenses (and neglecting others) would call that legitimacy into question. But it would be fine to educate potential licensors about license features, and encourage them to stick to the more common set.

Rosen's mention of the OSL elsewhere prompts John Cowan to announce his dislike of the license: it establishes a separate incompatible copyleft ecosystem or commons from the GPLv2 and GPLv3 ecosystems that already exist.

Rosen disagrees. Copyleft licenses are generally compatible regarding aggregations or collective works, and incompatible regarding joint or derivative works. But that isn't a problem because joint derivative works are rare in practice. The GPL/AGPL group is the odd one because the FSF interprets them to apply to static linking and other interactions. That is a problem with the FSF interpretation, not with copyright law.

Thorsten Glaser accuses Rosen of promoting an agenda here, and that the GPLv2/GPLv3 ecosystems are much more important in practice than the EPL/MPL/OSL ecosystem.

Topicality and Email Threading

Kevin Fleming is frustrated that discussion threads are often derailed by tangential discussions. Such discussions should be split off into a separate topic, so that other people don't have to wade through off topic discussion to find the relevant parts. Discourse allows messages to be moved to new topics after the fact.

John Cowan thinks that threading mail readers help, but that some amount of topic intermingling is unavoidable in any medium. Rick Moen shares the sentiment that threading is easy. “The above is internet 101 […] dont't blame the tool when the user cannot be bothered”. Regarding Discourse, it doesn't show any threading within a topic.

Luis Villa sees these OSI mailing lists as a disproportionally email-entrenched group. And even here, threading does not work in practice – hardly a case of Internet 101. This is dysfunctional. Having to master advanced email techniques seems like an unnecessary barrier to entry. Thankfully, other software does not blame the user – Discourse tries “to reach users where they actually read and write”. Moen responds.

Other discussions

Nigel Tzeng feels that the License-Review list was much more diverse in earlier times (2012), but is now dominated by Richard Fontana and Bruce Perens. Even though everyone is acting in good faith, this hurts engagement on the list. Bruce Perens notes he had been absent from the list for many years, only participating again since mid 2018. Were things really so different back in 2012? In the archives, Perens mostly finds the same posters as today.

Help Wanted!

Our current editor of the monthly License-Discuss and License-Review reports, Lukas Atkinson, will not be available to continue in June and July, and may have limited availability throughout the rest of the year. If you would like to join the OSI as list editor, or know someone who might, please contact OSI General Manager Patrick Masson. The list editor works on a freelance basis to provide monthly summaries of the License-Review and License-Discuss mailing lists.

Categories: FLOSS Research

Open Source Initiative Announces New Partnership with Software Liberty Association Taiwan

Wed, 2019-05-29 14:37

The Software Liberty Association Taiwan joins long list of Open Source Initiative Affiliate Members and growing representation in Asia.

PALO ALTO, Calif. - May 20, 2019 - The Open Source Initiative ® (OSI), the global organization working to promote and protect open source, is excited to announce the Affiliate Membership of the Software Liberty Association Taiwan (SLAT). Founded in 2001, SLAT is Taiwan’s first legal entity dedicated to Free and Open Source Software (FOSS), supporting both the development and user communities.  As an active community of advocates and technologists, SLAT both drives initiatives, and partners with existing projects, to promote FOSS, including the Open Source Software Application Consulting Center—a program fostering FOSS in Taiwan's schools.  

Critical to both the OSI's and open source projects' success is, as stated in the OSI mission, "building bridges between communities." Both the OSI and SLAT believe those organizations serving Free and Open Source Software communities should seek out ways to support each other—SLAT's Affiliate Membership is an excellent example of such collaboration.

“We’re thrilled to have SLAT join us in our work to advance Open Source Software and foster open source development,” said Patrick Masson, OSI General Manager. ”SLAT is already doing amazing work throughout Asia, and I hope we can compliment their efforts, and even help expand their good work through other OSI Affiliates. Open Source Software is a world-wide phenomena, so the OSI must commit to working globally.”

"We found a blue ocean in the world of FOSS," said Franklin Weng,  former SLAT president and current executive director. "Many  educational applications simply aren’t profitable enough for proprietary vendors to invest in  however are vital to students and schools . FOSS plays a critical role in educational software: programs like Kanagram, Geogebra, GCompris, Kalzium, Stellarium, and Kmplot, covering all kinds of subjects, and making education accessible.  Everyone, every kid, no matter rich or not, elite or not, they all can use these resources in their learning."

In  2015, SLAT launched the Software Liberation Movement, The goal, “explain to people that they have the freedom to choose whatever software tools they need according to their real-world requirements," explained Weng. "We, the users,  should be the ones who determine which tools we use for achieving our goals. However in reality, most people are bound by limitations or restrictions inherent to proprietary software.  We'd like to make people aware that they have many choices, and Open Source Software should be like that of 'public infrastructure' in the physical world—just like buses, trains, accessibility facilities, etc. The value of public infrastructures lies not in how many people are using them, but in the fact that they exist when people have such requirements."

Most recently SLAT has begun promotion of “Public Money Public Code“ in Taiwan. Such policies require that publicly financed software developed for the public sector be made publicly available under a Free and Open Source Software licence. “If it is public money, it should be public code as well.”  Again Weng, "OSI and SLAT are both committed to educating people about open source -- its spirit and value. The OSI reviews and certifies open source licenses, which we think is very important, clearly identifying what is open source. It's very important developers in Taiwan use OSI approved open source licenses. We're very happy to join OSI as an Affiliate Member to, together, support  initiatives like the Software Liberation Movement, and Public Money Public Code."

The OSI Affiliate Member Program is available at no-cost to nonprofits, educational institutions, and government agencies that support the OSI's mission to promote and protect open source software. As the steward of the Open Source Definition certifying Open Source Software Licenses, by establishing such certification as the standard for open source software development and distribution, and with the support of our Affiliate Membership, the OSI has become a cornerstone of software freedom.

About Software Liberty Association Taiwan
Founded on April 8, 2001, the Software Liberty Association (SLAT) is dedicated to serving the free and open source community, promoting free software and open source applications to promote community growth.To learn more about SLAT, visit: https://slat.org/

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 public charity with global vision based in California. For more information about the OSI, please see https://opensource.org .

 

Categories: FLOSS Research

Open Source Initiative Announces New Partnership with Software Liberty Association Taiwan

Wed, 2019-05-29 14:36

The Software Liberty Association Taiwan joins long list of Open Source Initiative Affiliate Members and growing representation in Asia.

PALO ALTO, Calif. - May 20, 2019 - The Open Source Initiative ® (OSI), the global organization working to promote and protect open source, is excited to announce the Affiliate Membership of the Software Liberty Association Taiwan (SLAT). Founded in 2001, SLAT is Taiwan’s first legal entity dedicated to Free and Open Source Software (FOSS), supporting both the development and user communities.  As an active community of advocates and technologists, SLAT both drives initiatives, and partners with existing projects, to promote FOSS, including the Open Source Software Application Consulting Center—a program fostering FOSS in Taiwan's schools.  

Critical to both the OSI's and open source projects' success is, as stated in the OSI mission, "building bridges between communities." Both the OSI and SLAT believe those organizations serving Free and Open Source Software communities should seek out ways to support each other—SLAT's Affiliate Membership is an excellent example of such collaboration.

“We’re thrilled to have SLAT join us in our work to advance Open Source Software and foster open source development,” said Patrick Masson, OSI General Manager. ”SLAT is already doing amazing work throughout Asia, and I hope we can compliment their efforts, and even help expand their good work through other OSI Affiliates. Open Source Software is a world-wide phenomena, so the OSI must commit to working globally.”

"We found a blue ocean in the world of FOSS," said Franklin Weng,  former SLAT president and current executive director. "Many  educational applications simply aren’t profitable enough for proprietary vendors to invest in  however are vital to students and schools . FOSS plays a critical role in educational software: programs like Kanagram, Geogebra, GCompris, Kalzium, Stellarium, and Kmplot, covering all kinds of subjects, and making education accessible.  Everyone, every kid, no matter rich or not, elite or not, they all can use these resources in their learning."

In  2015, SLAT launched the Software Liberation Movement, The goal, “explain to people that they have the freedom to choose whatever software tools they need according to their real-world requirements," explained Weng. "We, the users,  should be the ones who determine which tools we use for achieving our goals. However in reality, most people are bound by limitations or restrictions inherent to proprietary software.  We'd like to make people aware that they have many choices, and Open Source Software should be like that of 'public infrastructure' in the physical world—just like buses, trains, accessibility facilities, etc. The value of public infrastructures lies not in how many people are using them, but in the fact that they exist when people have such requirements."

Most recently SLAT has begun promotion of “Public Money Public Code“ in Taiwan. Such policies require that publicly financed software developed for the public sector be made publicly available under a Free and Open Source Software licence. “If it is public money, it should be public code as well.”  Again Weng, "OSI and SLAT are both committed to educating people about open source -- its spirit and value. The OSI reviews and certifies open source licenses, which we think is very important, clearly identifying what is open source. It's very important developers in Taiwan use OSI approved open source licenses. We're very happy to join OSI as an Affiliate Member to, together, support  initiatives like the Software Liberation Movement, and Public Money Public Code."

The OSI Affiliate Member Program is available at no-cost to nonprofits, educational institutions, and government agencies that support the OSI's mission to promote and protect open source software. As the steward of the Open Source Definition certifying Open Source Software Licenses, by establishing such certification as the standard for open source software development and distribution, and with the support of our Affiliate Membership, the OSI has become a cornerstone of software freedom.

About Software Liberty Association Taiwan
Founded on April 8, 2001, the Software Liberty Association (SLAT) is dedicated to serving the free and open source community, promoting free software and open source applications to promote community growth.To learn more about SLAT, visit: https://slat.org/

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 public charity with global vision based in California. For more information about the OSI, please see https://opensource.org .

 

Categories: FLOSS Research