Leading items

LinuxCon: The tragedy of the commons gatekeepers

During the 2012 LinuxCon North America conference, Richard Fontana, legal counsel at Red Hat, began a rather philosophical talk with what seemed to be a rather philosophical question: how do we decide what is free and open source software (FOSS), or rather, how do the organizations that have taken on this task make these decisions? However, he immediately pointed out that this is in fact a rather practical problem, since if we can't define FOSS, then it becomes rather difficult to reason and make decisions about it.

Many users and organizations need to make practical decisions based on the definition of FOSS. Individual users may have an ideological preference for FOSS. Software projects may need to know the status of software as FOSS for legal or policy reasons. Some of those projects may want to exclude non-free software; some Linux distributions may want to confine non-free software to a separate repository. Many governments nowadays have software procurement policies that are based on free software. Acknowledging the presence of Bradley Kuhn, executive director of the Software Freedom Conservancy (SFC) in the audience, Richard noted that the SFC requires the projects that it supports to be under a free software license. Some project-hosting web sites likewise have hosting policies predicated on a definition of FOSS. (Examples of such policies include those of SourceForge and Oregon State University's Open Source Lab.) Finally, some corporations have policies governing the use of open source software. All of these organizations care in a quite practical way about the definition of FOSS.

Deferring to authority

Richard didn't explicitly explain the origin of his talk title, but with a little reflection it became clear. The "commons" is of course the body of software that the community considers to be free. "Gatekeeping" is the process of admitting software to the category "free". What then is the "tragedy"? For Richard, it is the extent to which a freedom-loving community has surrendered the decision about what constitutes FOSS; instead, we commonly defer to authorities who make the decision for us. When people do consider the question of what is free software, they often say "the OSI [Open Source Initiative] has this figured out". Or they take the same approach with the FSF (Free Software Foundation).

Sometimes, people or organizations do consider this question more deeply, but they ultimately arrive at a justification to defer to an authority. Richard mentioned the example of the UK-based OSS Watch. OSS Watch recognizes that there are many definitions of open source, but for the purposes of their mission to advocate open source software in higher education, they've made the decision to accept the set of OSI-certified licenses as their definition. OSS Watch's justification for deferring to the OSI is that it is a quick way to accept that the code is open and "accepted by a large community, and if you've ever seen the OSI license list, you'll realize that is ridiculous." On the other hand, Fedora rejects the OSI as an authority for the definition of free software, and instead adopts the FSF's definition, on the basis that the FSF has the competence to make this definition. (Richard somewhat humorously expressed the Fedora approach as "What would RMS [Richard Stallman] do?")

Three organizations have tried to define FOSS: the FSF, the OSI, and the Debian project. These organizations have taken both a legislative and a judicial role, and Richard observed that this raises a separation-of-powers issue. He quoted Bradley's statement that "the best outcome for the community is for the logical conjunction of the OSI's list and the FSF's list to be considered the accepted list of licenses". The point here is that even though Bradley often disagrees with the OSI, he clearly sees that it's in the best interests of the community that no single group acts as legislator and judge when it comes to defining FOSS. Richard then turned to examining each of these three authorities, looking at their history and processes, and offering some criticism.

The Free Software Foundation (FSF)

The FSF has had a definition of software freedom as far back as 1986. By 1999 that definition had evolved into the well-known statement of the four software freedoms:

• The freedom to run the program, for any purpose.

• The freedom to study how the program works, and change it so it does your computing as you wish.

• The freedom to redistribute copies so you can help your neighbor.

• The freedom to distribute copies of your modified versions to others.

Richard pointed out that this a very compact definition of software freedom that covers many bases. It includes a legal definition (explaining at a very high level what permissions the software gives the user), technical criteria (source code must be available), policy justifications (freedom is important because it's important to be able to share), and "autonomousness" (it's important to control your own computing).

Since 1999, the FSF has maintained a list of free and non-free software licenses, with (often brief) rationales for the categorization of the licenses. Richard noted that the license list is accompanied by an evolving explanatory text that is rather useful. The FSF even gives a rule of construction which clarifies that they apply their criteria expansively when deciding if a license is free:

Richard then outlined some criticisms of the FSF, but emphasized that they were all mild. There seems to be a lot of inconsistency in the FSF's decisions about what is or is not a free software license. He likened the issue to Anglo-Saxon judicial systems, where the rationale for reaching a decision derives not just from the law but also from past legal decisions; an analogous process seems to happen in the FSF's categorization of software licenses. Furthermore, sometimes the rationale for decisions about particular licenses is too limited to be useful. Here, he mentioned the Perl Artistic License, version 1, which the FSF categorizes as non-free with the following humorous, but not very helpful explanation:

Another criticism that Richard raised is that the FSF is sometimes too formalist in its analysis of licenses, ignoring factors that are external to the license. Here, he mentioned the example of the Pine license. The Pine email client, developed at the University of Washington, had a BSD-style license for many years. But, at a certain point, and contrary to widespread understanding of such licenses, they claimed that the license did not give permission to redistribute modified versions. The FSF saw this as a textual problem, hinging on how particular words should be interpreted. But, the real problem was that "the University of Washington was being a [legal] bully and was giving an unreasonable interpretation of license."

Richard's final criticism of the FSF was that there was an appearance of bias. The FSF has multiple roles—steward of the GPL, maintainer of the free software definition, sponsor of the GNU project, and adjudicator on licenses—that can potentially conflict. "Could you imagine the FSF ever saying that a version of GPL is a non-free license?" Here, he gave an example relating to the GPLv2. Section 8 of that license allows the licensor to impose geographic restrictions on distribution for patent reasons. (The GPLv3 does not have such a clause.) In Richard's opinion, invoking that clause today would make the GPLv2 non-free (here, the implication was, non-free according to the FSF's own definition) "but I can't conceive of the FSF reaching that view".

Debian

Richard spent some time talking about Debian, beginning with some details of the Debian Social Contract (DSC). The DSC was written in 1997 by Bruce Perens. The Debian Free Software Guidelines (DFSG) form part of the DSC. The DFSG divides the software that Debian distributes into free and non-free parts, and this distinction has taken on a somewhat ideological dimension in the Debian community today. However, originally, the main focus was on being a high-quality noncommercial distribution fashioned on the Linux kernel project. One of the intentions was to be the upstream for successful commercial redistributors, and the reason for dividing software packages into "free" and "non-free" was to signal to their downstreams that there might be a problem with some software; in other words, the DFSG is a packaging policy. In later times, the Debian perspective became more ideological, as Bruce Perens increasingly stressed the free software ideal. And by now, the DFSG has taken on a life of its own, becoming something of a constitutional document for the Debian project.

Richard talked a bit about the process of how software comes to be defined as free in Debian. Essentially, this is a packaging decision made by a group of elite packagers—the FTP Masters—who, guided by the DFSG, determine whether software packages end up in "main" or "non-free". He criticized a few aspects of this process. The FTP Masters typically don't provide rationales for their licensing decisions (the rationale for the AGPLv3 was an exception that he noted approvingly). And though there is a process for review of their decisions, the FTP Masters have something approaching absolute power in these matters (but he emphasized that this was not much different from the situation with the FSF).

The Open Source Initiative (OSI)

The OSI's Open Source Definition (OSD) was crafted in 1998 by Eric Raymond working with Bruce Perens, using the DFSG as a basis. Richard characterized this as a somewhat strange approach, because the DFSG is very specific to the problems that a 1990s noncommercial distribution would face if it wanted to classify package software licenses in order to assist downstream commercial redistributors. By contrast, the OSD was intended to be a general definition of open source. Some parts of the reuse work, but some do not. For example, there is a clause in the OSD that refers to "distribution on [a] medium" that makes sense in the context of Debian packaging, but is out of place in what is supposed to be a general definition of open source. These problems probably spring from the fact that the authors wanted to quickly draft the OSD, and there was something near at hand in the form of the DFSG. Notwithstanding some oddities inherited from the DFSG, the OSD did improve some things, such as the definition of "source code".

Richard described OSI's license-certification process positively, noting first of all that it has a greater degree of transparency than the FSF and Debian processes. There is discussion on a public mailing list, and though the OSI board makes the final certification decision, there is evidence that they do take serious account of the mailing list discussions when making their decisions. He did however express doubts that the board pays much attention to the OSD, because "as I've, said it's a very strange document".

The OSI has faced a number of problems in its history, Richard said. Early on, it was accused of worsening the problem of license proliferation (which was ironic, as OSI had been one of the first groups to call attention to the problem). This was a consequence of the OSI's attempts to encourage businesses to use open source. There was indeed a lot enthusiasm from some businesses to do so, but several of them wanted to do what Netscape had already done: write their own license. Several of these licenses were approved by the OSI, and the decisions in some cases seem to have been hasty.

In 2007, the OSI faced a strong challenge to their authority in the form of what Richard called the "badgeware crisis". A number of companies were using a modified version of the Mozilla Public License that added a badgeware clause. This clause allowed licensors to require licensees to prominently display logos on program start-up. Although the licenses were unapproved by OSI, these companies posed a challenge to the OSI by calling their licenses "open source." (In the end, the OSI even approved a badgeware license.) "As dastardly as these companies were, I sort of admire them for challenging the idea that they should just defer to OSI as being authoritative."

Richard sees two problems that remain with the OSI to this day. One of these is OSI's categorization of certain licenses as "popular and widely used or with strong communities". In part, the goal of this categorization is to address the proliferation issue, by recommending a subset of the OSI-approved licenses. The membership of this category is somewhat arbitrary, and the fact that the licenses of several OSI board members are on the list has led to suggestions of cronyism and the criticism that the list rewards entrenched interests. A further problem with the idea that people should use "popular" licenses is that it discourages experimentation with new licenses, and "eventually we will need new licenses."

The second problem that Richard noted was inconsistency in the way that license approvals are considered. He cited two contrasting examples. In 2009, Carlo Piana submitted the MXM license on behalf of a client. The license included a rather limited patent grant, and because of that, it met strong opposition in the resulting mailing list discussions. Later, Creative Commons submitted the CC0 license. That license included a clause saying no patent rights were granted. Despite this, it initially received a positive response in mailing list discussions. It was only when Richard started raising some questions about the inconsistency that the tide started to turn against the CC0 license. Why did the two licenses receive such different initial responses? Carlo Piana suggested that it was the identity of the entity submitting the license that made the difference: Creative Commons was viewed positively, but the organization behind MXM was at best viewed neutrally.

Are software licenses enough to define FOSS?

Going off on a related tangent, Richard considered the rise of an idea that he termed "license insufficiency"—the idea that licenses alone are not sufficient to define open source. This idea is often posed as a suggestion that the definition of open source should be expanded to include normative statements about a project's community and development model. In other words, it's not enough to have a FOSS license and availability of source code. One must also consider other questions as well. Is there a public code repository? Is the development process transparent? Is it possible to submit a patch? Is the project diverse? Does it use a license whereby commercial entities are contributing patent licenses? In this context he mentioned Andy Oliver's "patch test" for defining open source. (Simon Phipps, who is now president of the OSI, has also written about some of these ideas, using the label "open-by-rule".) Richard said, "I don't agree with all of that, but I think its an interesting idea"

Conclusions

Richard concluded his talk with a few observations and recommendations. The first of these is that the historical tendency in the community to defer to institutions for the definition of FOSS is a problem, because those institutions have issues of accountability, bias, and transparency. People should be ready to question the authority of these institutions.

He observed that the FSF could learn from OSI's participatory approach to the license approval process. Conversely, the OSI should drop the Open Source Definition in favor of something more like FSF's Free Software Definition, which is far more appropriate than a definition based on the Debian Free Software Guidelines.

The FSF does the best job of providing rationale for its licensing decisions, but all three of the institutions that he talked about could do better at this.

Richard thought that the idea of defining FOSS based on open development criteria ("license insufficiency" above) is based on correct intuitions. We need to expand beyond the idea of licenses in terms of how we define software freedom.

Finally, Richard said that software projects can work together in developing and policing definitions of FOSS. He has seen distributors working together to share opinions on how they view licenses. Distributors are also in a unique role for policing software freedom, since they can sometimes pressure upstream projects to change their licenses. There is potential for this sort of collaborative approach to be generalized to the task of defining and policing the definition of FOSS.

[Michael would like to thank the Linux Foundation for supporting his travel to San Diego for LinuxCon.]

[2013-01-09 update: a recording of Richard's talk can be found on the Free as in Freedom web site.]

Comments (15 posted)

ALS: First signs of actual code

Left unchecked, talks about supply chains and long-term industry shifts could easily dominate a business-focused event like the Automotive Linux Summit, but they were balanced out in the 2012 schedule by several sessions that dealt with actual code. Leading the charge at the September 19-20 event in Gaydon, UK was the GENIVI Alliance, which announced three new automotive software projects that will be accessible to those outside GENIVI's member companies. There were also presentations from Yocto and Intel, along with some advice on where automotive Linux still needs contributors. In most cases, the actual code remains just out of reach, but it is still progress.

GENIVI announcements

GENIVI, of course, is a collaboration of more than 150 companies, including automakers, equipment suppliers, silicon merchants, and software consultancies. Its purpose is to hash out a common Linux-based platform for in-vehicle infotainment (IVI) systems, which the various members can build products on with a minimum of duplicated effort. But GENIVI operates behind closed doors; apart from the block diagrams found in slides and blog posts there has not historically been any access to the actual specification for those people not working with GENIVI itself. Moreover, GENIVI has an atypical approach to being an "open source platform": it is committed to using software available under open source licenses, but it does not make that software available to non-members.

The lack of a public specification document and the unavailability of the software have real implications for the Linux community, because GENIVI has long maintained that it would draw upon existing projects wherever possible — but new work would also be necessary to fill in gaps in the stack. At ALS, Pavel Konopelko estimated that the GENIVI platform would consist of 80% existing "community" code, 15% community code extended by GENIVI to meet specific requirements, and 5% purely original work. Some of that work has already seen the light of day, such as the AF_BUS patches, but several other pieces have remained absent.

On the first day of ALS, though, GENIVI announced [PDF] three specific projects that it will open up for public consumption. They are an IVI audio management layer, an IVI screen layer manager, and a logging and tracing framework for use with diagnostic messages. The three projects are set to be hosted on Linux Foundation infrastructure, although so far the sites and code repositories have not appeared. There is a description of each of the components available now on the GENIVI web site, which sheds a bit more light on their scope — although the explanations are not always crystal clear.

The audio manager, for example, implements an API for routing audio that is independent of the hardware and software routing frameworks underneath. That would appear to place it above PulseAudio in the typical Linux stack, while providing the same API if a hardware audio routing mechanism is available instead. The GENIVI specification does not make PulseAudio mandatory; it only mandates (as an "abstract component") that an audio router be provided. The audio-routing problem in IVI includes use cases not encountered in desktop setups, such as alarms (triggered by bumper proximity sensors, for example) that interrupt any other audio streams, and routing sound from a single media source to multiple rear-seat entertainment (RSE) units. The hardware-or-software approach described for the audio manager suggests that there are GENIVI members intent on producing vehicles where such audio routing is handled by onboard hardware.

Similarly, the screen layer manager is described as handling hardware-accelerated compositing, but by implementing an API that can deal both with software video sources like applications and with direct hardware sources like reverse-view cameras. The description of this component also observes that existing IVI implementations tend to build such layer management functionality directly into their GUI front-end (which, in IVI circles, is usually referred to as a Human-Machine Interface or HMI). Since HMI is generally reserved as one of the vendor-specific "differentiating components" in a product, a standard screen layer manager will presumably reduce duplication.

The last component of the three is the Diagnostic Log and Trace (DLT) project, which is described as an abstraction layer for several different diagnostic logging protocols. It is said to support system- and user-level logging, predefined control messages, and callbacks, and to connect to syslog or other existing logging systems.

At this stage, all three projects are (so to speak) "announcement-ware," but assuming that the code and infrastructure follows, they represent a major step forward for GENIVI. If one looks at the GENIVI platform block diagram (for example, the version on slide 9 of Konopelko's presentation [PDF]), there are quite a few components still designated placeholders or abstract requirements. It is hard to see how the missing pieces fit into the 80-15-5 percentages cited, but at least the availability of some GENIVI-authored components should help bring the whole picture into clearer view for those not part of the GENIVI Alliance.

Yocto, Intel, and others

There are indirect ways in which one can explore a GENIVI system already, however, by downloading some member company's GENIVI-compliant operating system. There are a few free options, such as Ubuntu's IVI remix and Tizen IVI. Holger Behrens from Wind River presented another possibility, the Yocto project's meta-ivi layer. Meta-ivi is a Yocto component that will pull in dependencies for GENIVI compliance.

It is designed to be used with Poky, the Yocto build environment, and pulls in the mandatory components of the latest GENIVI reference releases, plus the meta-systemd layer, a separate Yocto component that adds systemd. The current release of meta-ivi dates from May 16, 2012, and is based on the GENIVI 2.0 specification and Yocto 1.2 (an update is due in mid-October to bump the code up to Yocto 1.3 and GENIVI 3.0). It builds and configures the GENIVI and systemd layers, plus a few standard components to fill in GENIVI's optional components (e.g., PulseAudio and GStreamer).

Currently, building a meta-ivi system requires login credentials for GENIVI, because it pulls from the alliance's Git repository. Behrens said repeatedly that this requirement is likely to go away as GENIVI opens up access to outsiders, but for the moment there is no way around it. A bigger limitation, he said, was that currently meta-ivi is designed only for ARM's Versatile Express A9 boards. This is strictly a developer-power issue, he added, imploring interested parties to contribute with "board support, board support, and board support."

Luckily, there were some software options available today, as well. Intel's Kevron Rees presented his work on the Automotive Message Broker (AMB), a vehicle communication abstraction layer. The project is an extension of his previous effort, Nobdy. It provides a source/sink model for applications to connect to vehicle data sources (from OBD-II diagnostic messages to sensor output) without worrying about the underlying mechanics source of the data. It allows multiple sinks to subscribe to messages from the same source, and the message routing engine (which Rees said was modeled on GStreamer) allows for intermediate nodes that could perform transformations on the data, such as filtering or message throttling.

The current version of AMB supports GPS, OBD-II, and CAN bus sources (the latter of which he demonstrated using a video gaming "steering wheel" controller). Only two sinks are implemented at the moment, D-Bus and Web Sockets. The D-Bus output, he explained, was an obvious choice because it provides a property and signaling system for free, and allows Smack-based security policies. The lack of security in Nobdy was one of the principle reasons he decided to undertake a rewrite. The demonstration was short but entertaining; it utilized a dashboard display application called GhostCluster to report mock speed and direction information from the game controller, and allowed access to faux rear-view cameras, which were implemented with webcams.

Jeremiah Foster of Pelagicore also discussed the paucity of software available to interested developers in a session examining progress between the automotive industry and the open source community. Foster is the baseline integration team leader at GENIVI, but as he explained, he spent quite some time beforehand working on the community side as the Maemo "debmaster." The talk included several points about how the automotive industry and traditional open source differed, such as the long-term partnerships in place between automakers and tier-one suppliers. Some of the disconnects are changing already, he said, such as the automotive industry's understanding of how to work with software licenses, but others remain unclear, such as the lines of legal responsibility in cases where software contributes to an accident.

A key point, he said, is that automakers do recognize that rewriting software stacks for every new product is incredibly wasteful, and there are opportunities for developers and agile software companies to do big business during the transition. He then outlined a number of areas where interested developers could work on automotive-related problems.

The first was fast boot, which is required by regulations (such as requiring that a rear-view camera start showing live video to the display less than two seconds after startup). GENIVI has adopted systemd to tackle this requirement, he said, though it is not yet complete. Another systemd-derived feature is "last user context" (LUC), in which a car remembers and restores environmental settings for multiple drivers (such as audio and temperature preferences, plus physical options like mirror and seat adjustment). LUC remains a subject where considerable work is required.

There are also several standard Linux components that automakers and software vendors frequently replace with proprietary components because the open source versions are incomplete, he said. These include BlueZ, ConnMan, and Ofono. All three are missing features and require testing in more configurations. Similarly, IVI systems require some mechanism for data persistence, such as remembering recently-accessed files or playlists. Existing solutions like SQLite have not proven popular with IVI vendors, who would be happy to see additional work.

Finally, he said, there remains a lot of work to be done porting and packaging existing automotive software for the distributions used by developers. The existing IVI distributions (such as Ubuntu and Tizen's IVI flavors) tend to start with a minimalist system and add automotive-specific packages, but this results in a system that developers cannot use for everyday work. The majority of Linux developers, he said, would rather port new software than change distributions. Consequently, bringing the IVI software to existing distributions will attract more developers than will continuing to roll out IVI-only embedded distributions. Bringing automotive packages to desktop distributions could also help the community build its own answer to the pieces that commercial vendors prefer to keep proprietary, like HMI.

Although it was good to hear that GENIVI is opening up more of its code, the three projects announced are just a beginning. GENIVI and other automotive Linux players do seem to recognize that there is a void to be bridged between the industry and the community, though. If the alliance does indeed make its Git repositories publicly accessible, that will break down a major barrier to entry for the potentially enormous talent pool of volunteer contributors.

[The author would like to thank the Linux Foundation for travel assistance to ALS.]

Comments (none posted)

XDC2012: The X.Org Developers' Conference

The 2012 X.Org Developers' Conference took place in the charming Bavarian city Nuremberg (Nürnberg), over the period 19-21 September 2012, hosted at the headquarters of the Linux distributor, SUSE.

The conference program page provides links to pages detailing the various sessions; in many cases, those pages contain links to slides and videos for the sessions. Simon Farnsworth took some rough notes from each session, and these have been placed on a "proceedings" page; that page also has links to videos of nearly all of the talks.

LWN has coverage of selected talks; these will be linked off this page as they appear.

• Status report from the X.Org Board

• Graphics stack security: what are the security problems in X11, and how can they be avoided in Wayland/Weston?

• Programming languages for X application development: to what extent is the choice of programming language important in terms of making it easier to build desktop applications?

• OpenGL futures: what are the plans for the OpenGL ABI?

Above: XDC2012 conference group photo

Above: Kristian Høgsberg bending the laws of desktop graphics on Weston

Comments (none posted)

XDC2012: Status report from the X.Org Board

On the first day of the 2012 X.Org Developers' Conference, Bart Massey kicked off a short presentation from the Board of Directors of the X.Org Foundation, running through the current status of the foundation and its recent achievements. He began by noting that, with much assistance from the Software Freedom Law Center, the foundation has now achieved 501(c)(3) tax status as a US nonprofit. In addition, the foundation is now a member of the Open Invention Network (OIN). Although the foundation can't offer any patents to OIN (because it owns none), "we do have a lot of prior art". Much of what the X developers are doing is innovative and potentially patentable [by others], and "if you want that not to happen, you should talk to us and OIN".

X.Org did not have any Google Summer of Code (GSoC) projects approved this year, and Bart noted the need for a rethink about how to approach GSoC in the future. On the other hand, in the last year there were four successful projects (and one failed project) in X.Org's own similar "Endless Vacation of Code" (EVoC) program, and all of the successful EVoC students were funded to travel to Nuremberg for the conference. (A session on day one of the conference reviewed the status of the EVoC program, looking at the goals of the program and how its implementation could be improved; video of the session can be found here.)

In the two days immediately preceding the conference, there was a book sprint. This followed on from an earlier book sprint in March, which worked on the creation of a developer's guide that was to some extent client-side focused. The more recent sprint aimed to complete Stéphane Marchesin's Driver Development Guide. There are now 119 pages of documentation that is still rough and in need of editing, but a version should be on the wiki in a few days. He noted that one of the explicit points of adding more documentation was to attract new X developers by lowering the barriers to understanding the X system.

Bart noted that the foundation currently faces a number of challenges. The financial organization is better than it has been for a while, but the once large budget surplus is now starting to run down, to the point where some real effort needs to be spent on fund raising. In a brief treasurer's report, Stuart Kreitman expanded on this point: at the current rate of spending (US$20k to US$30k per year), there's about three year's buffer. The old days when several large UNIX workstation vendors gave large donations have—along with those vendors—long gone. New funding sources will be needed, and X.Org may need to rely more on smaller donations.

Bart pointed out a number of other challenges that X faces. As with many projects, but perhaps especially notable because X is such a fundamental part of our day-to-day infrastructure, X needs more developers, and Bart emphasized the need for ideas on how to attract new developers. There remain some infrastructure problems to be resolved (notably, the X.Org web site was down a number of times in the lead-up to the conference). Then there is the whole "future of Wayland thing". Although the Board does not set technical directions, "it's clear that Wayland is part of the X world", and the question is how to support the transition to a potentially "Wayland world".

But, notwithstanding these and other challenges, Bart stressed that "I couldn't be more excited about what's happening", and certainly the level of interest and detail in the three days of presentations seem to justify his excitement.

A pointer to a video that includes the status session can be found here.

Comments (6 posted)

Page editor: Jonathan Corbet
Next page: Security>>