FLOSS Research

The Faces of Open Source: Kate Stewart

Open Source Initiative - Tue, 2017-08-15 10:45

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

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


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

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

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

Other episodes:

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

Categories: FLOSS Research

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

Open Source Initiative - Mon, 2017-08-14 22:31

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

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

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

Categories: FLOSS Research

7 Rules For Engaging Communities On Legal Matters

Open Source Initiative - Fri, 2017-08-11 11:44

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

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

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

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

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

Categories: FLOSS Research

The Faces of Open Source: Luis Villa

Open Source Initiative - Tue, 2017-08-08 17:35

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

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


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

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

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

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

Other episodes

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

Categories: FLOSS Research

Give Generously! Seven Ways To Help Open Source

Open Source Initiative - Sat, 2017-08-05 16:20

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

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

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

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

1. Buy from community members

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

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

2. Promote the project

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

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

3. Participate in the community

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

4. Contribute to the project

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

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

5. Commission improvements

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

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

6. Hire committers

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

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

7. Make cash donations

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

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

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

Categories: FLOSS Research

Sharing "The Faces of Open Source"

Open Source Initiative - Tue, 2017-08-01 09:42

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

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

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

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


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

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

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

Armijn Hemel:

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

Categories: FLOSS Research

Public Domain Is Not Open Source

Open Source Initiative - Fri, 2017-07-28 08:45

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

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

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

  • Open Source” describes a subset of free software that is made available under a copyright license approved by the Open Source Initiative as conforming with the Open Source Definition. Having a standards body for licenses — one which ratifies the consensus of an open community of license reviewers — saves individuals from needing to each seek out a legal advisor to tell them whether a given license does in fact give them the rights they need to build or deploy the software they want. By providing easy certainty, open source gives people permission in advance to meet their own needs and innovate with technology.
  • Public Domain” means software (or indeed anything else that could be copyrighted) that is not restricted by copyright. It may be this way because the copyright has expired, or because the person entitled to control the copyright has disclaimed that right. Disclaiming copyright is only possible in some countries, and copyright expiration happens at different times in different jurisdictions (and usually after such a long time as to be irrelevant for software). As a consequence, it’s impossible to make a globally applicable statement that a certain piece of software is in the public domain.

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

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

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

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

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

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

Categories: FLOSS Research

Assume Good Faith

Open Source Initiative - Fri, 2017-07-21 10:03

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

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

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

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

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

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

How to assume good faith

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

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

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

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

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

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

Categories: FLOSS Research

Why OSI License Approval Matters

Open Source Initiative - Fri, 2017-07-14 10:59

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

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

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

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

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

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

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

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

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

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

Categories: FLOSS Research

Permissive and Copyleft Are Not Antonyms

Open Source Initiative - Fri, 2017-07-07 13:16

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

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

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

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

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

Instead of “copyleft” use “reciprocal licensing”

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

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

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

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

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

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

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

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

Instead of “permissive” use “nonreciprocal”

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

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

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

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

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

Categories: FLOSS Research

OSI extends support to OW2 as Associate Organization.

Open Source Initiative - Sun, 2017-07-02 21:43

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

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

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

    About the Open Source Initiative

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

    About OW2

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

Categories: FLOSS Research

Growing The Community

Open Source Initiative - Tue, 2017-06-20 23:01

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

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

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

Individual Contributors

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

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

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

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

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

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

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

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

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

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

Balance Yielding Benefit

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

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

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

Categories: FLOSS Research

OW2 Consortium: Building Beyond Europe

Open Source Initiative - Thu, 2017-06-15 08:12

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

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

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

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

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

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

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

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

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

Masson: What about challenges?

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

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

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

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

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

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

Masson: How has OW2 worked to address those challenges?

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

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

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

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

Categories: FLOSS Research

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

Open Source Initiative - Mon, 2017-06-12 17:57

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

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

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

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

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

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

Categories: FLOSS Research

Proprietary Election Systems: Summarily Disqualified

Open Source Initiative - Fri, 2017-04-28 17:06

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

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

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

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

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

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

Both I and CAVO are available for further information.

Best regards,
Brent Turner
Secretary, California Association of Voting Officials

Categories: FLOSS Research

React to React

Open Source Initiative - Thu, 2017-04-27 07:36

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

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

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

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

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

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

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

Bicho 0.9 is comming soon!

LibreSoft Planet - Thu, 2011-06-09 10:06

During last months we’ve been working to improve Bicho, one of our data mining tools. Bicho gets information from remote bug/issue tracking systems and store them in a relational database.



The next release of Bicho 0.9 will also include incremental support, which is something we’ve missed for flossmetrics and for standalone studies with a huge amount of bugs. We also expect that more backends will be created easily with the improved backend model created by Santi Dueñas. So far we support JIRA, Bugzilla and Sourceforge. For the first two ones we parse HTML + XML, for sourceforge all we have is HTML so we are more dependent from the layout (to minimize that problem we use BeautifulSoup). We plan to include at least backends for FusionForge and Mantis (which is partially written) during this year.

Bicho is being used currently in the ALERT project (still in the first months) where all the information offered by the bug/issue reports will be related to the information available in the source code repositories (using CVSAnaly) through semantic analysis. That relationship will allow us to help developers through recommendations and other more pro-active use cases. One of my favorites is to recommend a developer to fix a bug through the analysis of the stacktraces posted in a bug. In libre software projects all the information is available in the internet, the main problem (not a trival one) is that it is available in very different resources. Using bicho against the bts/its we can get the part of the code (function name, class and file) that probably contains the error and the version of the application. That information can be related to the one got from the source code repository with cvsanaly, in this case we would need to find out who is the developer that edit that part of the code more often. This and other uses cases are being defined in the ALERT project.

If you want to stay tunned to Bicho have a look at the project page at http://projects.libresoft.es/projects/bicho/wiki or the mailing list libresoft-tools-devel _at__ lists.morfeo-project.org


Categories: FLOSS Research

ARviewer, PhoneGap and Android

LibreSoft Planet - Thu, 2011-06-09 05:44
ARviewer is a FLOSS mobile augmented reality browser and editor that you can easily integrate in your own Android applications. This version has been developed using PhoneGap Framework. The browser part of ARviewer draws the label associated with an object of the reality using as parameters both its A-GPS position and its altitude. The system works both outdoors and indoors in this latest case with location provided by QR-codes. ARviewer labels can be shown through a traditional list based view or through an AR view a magic lens mobile augmented reality UI.    The next steps are: 
  • Testing this source code in IOS platform to check the real portability that phoneGap provide us.
  • We plan to add the “tagging mode” with phoneGap to allow tag new nodes/objetcs from the mobile. 
  Are very very similar the next images, right? We only have found a critical problem with the refresh of nodes in the WebView using PhoneGap. We will study and analyze this behavior.  

ARviewer PhoneGap


ARviewer Android (native)

  More info: http://www.libregeosocial.org/node/24  Source Code: http://git.libresoft.es/ARviewer-phoneGap/  Android Market: http://market.android.com/details?id=com.libresoft.arviewer.phonegap
Categories: FLOSS Research

Finding code clones between two libre software projects

LibreSoft Planet - Thu, 2011-05-12 09:05

Last month I’ve been working in the creation of a report with the aim of finding out code clones between two libre software projects. The method we used was basically the one that was detailed in the paper Code siblings: Technical and Legal Implications by German, D., Di Penta M., Gueheneuc Y. and Antoniol, G.

It is an interesting case and I’m pretty sure this kind of reports will be more and more interesting for entities that publish code using a libre software license. Imagine you are part of a big libre software project and your copyright and even money is there, it would be very useful to you knowing whether a project is using your code and respecting your copyright and the rights you gave to the users with the license. With the aim of identifying these scenarios we did in our study the following:

  • extraction of clones with CCFinderX
  • detection of license with Ninka
  • detection of the copyright with shell scripts

The CCFinderX tool used in the first phase gives you information about common parts of the code, it detects a common set of tokens (by default it is 50) between two files, this parameter should be changed depending on what it is being looked for. In the following example the second and third column contain information about the file and the common code. The syntax is (id of the file).(source file tokens) so the example shows that the file with id 1974 contains common code with files with id 11, 13 and 14.

clone_pairs {
19108 11.85-139 1974.70-124
19108 13.156-210 1974.70-124
19108 14.260-314 1974.70-124
12065 17.1239-1306 2033.118-185
12065 17.1239-1306 2033.185-252
12065 17.1239-1306 2033.252-319
12065 17.1239-1306 2141.319-386

In the report we did we only wanted to estimate the percent of code used from the “original” project in the derivative work, but there are some variables that are necessary to take into account. First, code clones can appear among the files of the same project (btw this is clear sign of needing refactorization). Second, different parts of a file can have clones in different files (a 1:n relationship) in both projects. The ideal solution would be to study file by file the relationship with others and to remove the repeated ones.

Once the relationship among files is created is the turn of the license and copyright detection. In this phase the method just compares the output of the two detectors and finally you get a matrix where it is possible to detect whether the copyright holders were respected and the license was correctly used.

Daniel German’s team found interesting things in their study of the FreeBSD and Linux kernels. They found GPL code in FreeBSD in the xfs file system. The trick to distribute this code under a BSD license is to distribute it disabled (is not compiled into FreeBSD) and let the user the election of compiling it or not. If a developer compiles the kernel with xfs support, the resulting kernel must be distributed under the terms of the GPLx licence.

Categories: FLOSS Research

OpenBSD 4.9 incorpora el sistema /etc/rc.d

LibreSoft Planet - Wed, 2011-05-04 17:23
Algo de historia  

Como cualquier administrador de sistemas Unix sabe, init es el primer proceso en ejecución tras la carga del kernel, y da inicio a los demonios ("servicios") estándar del sistema. En el Unix original de Bell Labs, el proceso init arrancaba los servicios de userland mediante un único script de shell denominado /etc/rc. La Distribución de Berkeley añadió años después otro script denominado /etc/rc.local para arrancar otros servicios. 

Esto funcionó así durante años, hasta que Unix se fue fragmentando y, con la aparición del software empaquetado de terceros, la versión System V del Unix de AT&T introdujo un nuevo esquema de directorios en /etc/rc.d/ que contenía scripts de arranque/parada de servicios, ordenados por orden de arranque, con una letra-clave delante del nombre de fichero (S- arrancar servicios y K- detener el servicio). Por ejemplo: S19mysql inicia [S] el servicio mysql. Estos scripts (situados en /etc/init.d) se distribuyeron en niveles de ejecución (runlevels, descritos en /etc/inittab), asociando los scripts con enlaces simbólicos en cada nivel de ejecución (/etc/rc0.d, rc1.d, rc2.d, etc.). Los niveles de ejecución en cada directorio representan la parada, el reinicio, arranque en monousuario o multiusuario, etc. Este esquema, conocido como "System V" (o "SysV"), es, por ejemplo, el que adoptaron las distribuciones de Linux (con algunas diferencias entre ellas en cuanto a la ubicación de subdirectorios y scripts). Tenía la ventaja de evitar el peligro de que cualquier error de sintaxis introducido por un paquete pudiera abortar la ejecución del único script y por tanto dejar el sistema en un estado inconsistente. A cambio, introdujo cierto grado de complejidad en la gestión y mantenimiento de scripts de inicio, directorios, enlaces simbólicos, etc. 

Otros sistemas de tipo Unix, como los BSD, mantuvieron el esquema tradicional y simple de Unix, con solo uno o dos únicos ficheros rc y sin niveles de ejecución[*], si bien fueron incorporando algunos otros aspectos del esquema SysV de inicialización de los servicios del sistema. Por ejemplo, NetBSD incluyó un sistema de inicio System V similar al de Linux, con scripts individuales para controlar servicios, pero sin runlevels. FreeBSD, a su vez, integró en 2002 el sistema rc.d de NetBSD y actualmente cuenta con decenas de demonios de inicio que funcionan de forma análoga a SysV: 

$ /etc/rc.d/sshd restart


OpenBSD incorpora /etc/rc.d


OpenBSD, sin embargo, no había adoptado hasta ahora el subsistema de scripts individuales para controlar los servicios, lo que a veces causaba cierto pánico, como si les faltase algo esencial, a quienes desde el mundo Linux (u otros Unices)

entraban por primera vez en contacto con este sistema (aunque luego la cosa tampoco era tan grave, es cuestión de hábitos). La actual versión OpenBSD 4.8, publicada en noviembre de 2010, todavía utiliza únicamente dos scripts de inicio (/etc/rc y /etc/rc.local). En OpenBSD 4.9, que se publicará el próximo 1 de mayo, se ha implementado por primera vez esta funcionalidad mediante el directorio /etc/rc.d

Como suele ser habitual en OpenBSD, no se implementa algo hasta que se está seguro que se gana algo y que hay un modo sencillo y fiable de utilizarlo para el usuario final. El mecanismo es análogo al de otros sistemas de tipo Unix, pero más sencillo y con algunas sutiles e importantes diferencias que vale la pena conocer. Veámoslo. 

Descripción del nuevo subsistema /etc/rc.d de OpenBSD  

En /etc/rc.conf (donde se incluye las variables de configuración para el script rc)  nos encontraremos una nueva variable denominada rc_scripts: 

# rc.d(8) daemons scripts # started in the specified order and stopped in reverse order rc_scripts=

Incluimos en esa variable (o mejor, como se recomienda siempre, en /etc/rc.conf.local, un fichero opcional que sobreescribe las variables de /etc/rc.conf) los demonios que deseamos arrancar de inicio, por orden de arranque:

rc_scripts="dbus_daemon mysql apache2 freshclam clamd cupsd"

Los scripts de inicio de servicios residirán, como suele ser habitual, en el directorio /etc/rc.d. Pero una diferencia clave es que, aunque los scripts estén ahí situados, no arrancará nada automáticamente que no esté listado en la variable rc_scripts, siguiendo el principio de OpenBSD de evitar presumir automatismos predeterminados. Cada script responderá a las siguientes acciones:

  • start    Arranca el servicio si no está ya corriendo.
  • stop     Detiene el servicio.
  • reload   Ordena al demonio que recargue su configuración.
  • restart  Ejecuta una parada del demonio (stop), y a continuación lo inicia (start).
  • check    Devuelve 0 si el demonio está corriendo o 1 en caso contrario. 

Actualmente, este sistema solo se usa para demonios instalados desde paquetes, no para el sistema base de OpenBSD. Por ejemplo, para gestionar los estados del servicio "foobar", que habremos antes instalado desde ports o paquetes, basta ejecutar:

/etc/rc.d/foobar reload /etc/rc.d/foobar restart /etc/rc.d/foobar check /etc/rc.d/foobar stop

La última orden ("stop") se invoca también en un reinicio (reboot) o parada (shutdown) desde /etc/rc.shutdown, en orden inverso al que aparece en la variable en rc_scripts, antes de que se ejecute la orden "stop/reboot" para todo el sistema. No es necesario preocuparse por el orden de ejecución o por el significado de S17 al comienzo del nombre de los scripts.

Otra ventaja de esta implementación es lo extraordinariamente sencillos que es escribir esos scripts, frente a otras implementaciones que precisan scripts de decenas o incluso cientos de líneas. En su forma más simple:

daemon="/usr/local/sbin/foobard" . /etc/rc.d/rc.subr rc_cmd $1

Un ejemplo algo más complejo:

#!/bin/sh # # $OpenBSD: specialtopics.html,v 1.15 2011/03/21 21:37:38 ajacoutot Exp $ daemon="${TRUEPREFIX}/sbin/munin-node" . /etc/rc.d/rc.subr pexp="perl: ${daemon}" rc_pre() { install -d -o _munin /var/run/munin } rc_cmd $1

Como puede observarse, el script típico solo necesita definir el demonio, incluir /etc/rc.d/rc.subr y opcionalmente definir una expresión regular diferente a la predeterminada para pasársela a pkill(1) y pueda encontrar el proceso deseado (la expresión por defecto es "${daemon} ${daemon_flags}").

El nuevo script debe colocarse en ${PKGDIR} con extensión .rc, por ejemplo foobard.rc. TRUEPREFIX se sustituirá automáticamente en el momento de instalarlo.

La sencillez y limpieza es posible gracias al subsistema rc.subr(8), un script que contiene las rutinas internas y la lógica más compleja para controlar los demonios. Así y todo, es muy legible y contiene menos de 100 líneas. Existe también una plantilla para los desarrolladores de paquetes y ports que se distribuye en "/usr/ports/infrastructure/templates/rc.template".

Y eso es todo. Cualquier "port" o paquete que necesite instalar un demonio puede beneficiarse ahora de los scripts rc.d(8). Quizá el nuevo sistema no cubra todos los supuestos, pero cubre las necesidades de los desarrolladores de ports para mantener un sistema estándar y sencillo para arrancar servicios). En marzo de 2011, ya hay más de 90 ports de los más usados que los han implementado. Por supuesto, el viejo sistema sigue funcionando en paquetes no convertidos, pero es indudable que los desarrolladores de OpenBSD (especial mención para Antoine Jacuotot (jacuotot@) y Robert Nagy (robert@)) han logrado una vez más un buen balance entre simplicidad y funcionalidad. Por supuesto, para ampliar detalles, nunca debe eludirse leer las páginas correspondientes del manual: rc.subr(8), rc.d(8), rc.conf(8) y rc.conf.local(8) y la documentación web


(*) Que BSD no implemente "/etc/inittab" o "telinit" no significa que no tenga niveles de ejecución (runlevels), simplemente es capaz de cambiar sus estados de inicio mediante otros procedimientos, sin necesidad de "/etc/inittab".

Categories: FLOSS Research
Syndicate content