Let me offer a countervailing opinion, in detail. First, let me say that this is /my opinion/. Despite the @redhat.com address, this is not Red Hat's position, it's mine. Second, this is a /preliminary attempt/ to organizing a wide range of thoughts that I've been seeing across this list over the past 2-3 weeks. I half expect that this will get shouted down, perhaps by people sitting near me, but if it's a step in the direction of separating and solving the issues that this discussion has touched, I'm happy to take it as far as I can. Finally, a word about the diagram: I think that Warren's recently posted Fedora submissions process was a great start, but it did not reach far enough. This diagram attempts to show how actors within the community can draw from the universe of available packages and place them into some meaningful Fedora context. Shameless plug: I'll be at OSCON next week, so anybody who wants to flame/praise me in person can do so next week in Portland. M On Wed, 2004-07-21 at 04:55, Warren Togami wrote: > Bill Nottingham wrote: > > Leonard den Ottolander (leonard@xxxxxxxxxxxxxxxxx) said: > > > >>>I don't know that there was ever a firm decision as in a vote was taken > >>>or some dictator laid down the law. I just remember someone suggesting > >>>this approach and I said "that sounds good to me" when asked, and I > >>>don't know if it went anywhere. > >> > >>I also falsely interpreted your reaction as being a confirmation of > >>adopted policy. > >> > >>How do the Red Hat developers perceive this issue? Is the "intersection > >>between OSI and FSF" approach a good enough compromise for you? > > > > > > It's probably more-or-less mirrors the policy now. Certainly a pine > > package that we could only apply official security patches (and where > > other patches would be by negotiation) doesn't really fit the definition > > of what we'd normally consider. > > > > Moreover, we'd want whoever takes the stuff from Fedora Core to > > be able to redistribute and rebuild as well (of course, you > > have to watch trademark issues here.) > > > > Bill > > I notice that Bill said "Fedora Core" in the last paragraph. I > personally have the opinion that if we can get away with it legally, > pragmatism takes precedent to principles. But then again I also believe > much of the Debian social contract stuff is a complete waste of time, > and not conducive to our ability to eventually triumph over the > proprietary forces. > > http://macromedia.mplug.org/ > One example of where pragmatism is more important than principles is > this closed source abomination. We clearly would be far worse off today > in end-user desktop viability without this software. This is not a > matter open to debate with me. For the moment I believe: > The enemy of our enemy is our friend, for today at least. > > This being said, unless legal tells me otherwise, I personally wish to > accept anything in Extras that is not legally risky (as well as > technically sound, etc.) I care less about redistribution rights. That > is their problem, not ours. > > I do agree that Fedora Core should always be 100% Open Source. I also > believe that Extras need not be this strict. If you dislike some part > of Extras, then just don't use it. > > https://bugzilla.fedora.us/show_bug.cgi?id=1457 > On a somewhat related matter, if you feel restricted by pine's lack of > "Freedom", then give the new cone package a try. I am very impressed by > what I see with cone, and it is Open Source Software, unlike pine. It > should be published in Extras stable real soon now. > > Warren Togami > wtogami@xxxxxxxxxx >
Attachment:
update-process.dia
Description: application/dia-diagram
Michael Tiemann's Fedora Policy Strawman Draft 0.1 July 22, 2004 Fedora Goals and Positioning A clear goal of Fedora from the beginning (though very poorly communicated at the outset, and to this date for that matter) was to be a platform for open source innovation. Where Red Hat's Enterprise Linux would be stable, Fedora would be good quality, but not unchanging. Where Enterprise Linux would be supported with back-patch fixes, Fedora would roll forward to pick up the latest patches in the context of the latest packages. Where Enterprise Linux would make conservative decisions based on proven technologies, Fedora would give new technologies a chance to prove themselves or fail in noble ways. And where Enterprise Linux was exclusively defined and managed by Red Hat, Fedora would be open to contributors who shared our principles and practices for meaningful innovation. Most importantly, while Fedora would be constantly innovating, it would also be informing, creating a pathway for open source technology to migrate into production environments more rapidly, more robustly, and less disruptively than any competing development model. The goals of Fedora are a two-way street for the open source community. Of course Red Hat benefits by having thousands of contributors, hundreds of thousands of users and testers, and unfettered access to open source innovation that drives the value of our subscription-based business. But mainstream contributors benefit as well: a platform driven by technology rather than revenue goals, the network effect that such a best-of-class platform provides, and the opportunity to see one's work making it into production sooner rather than never all make Fedora an attractive place to be. For both Red Hat and community contributors, the whole is greater than the sum of its parts, and the job of the Fedora Steering Committee (and all other principles, policies, procedures, and people) should be to maximize what the whole can be, both today and in the future. Fedora Over-arching Definitions A Fedora Collection is a set of RPM packages which, together, meet a defined set of criteria. Fedora Core 1 and Fedora Core 2 are specific examples of two such collections. Fedora Core an the abstract example of a collection meeting its specific criteria. An RPM package consists of a variety of elements (as specified in the RPM spec file) and also has a number of properties. At the Fedora project level, the following package properties help define the potential disposition of a given package in a given Fedora collection: * Source and License. Is source code included with the package? If not, does the package need and deserve a "binary-only exception"? If source is available with the package, is the license governing the entire package open source (i.e., OSD-compliant)? If so, is it also free software? [Meets OSS and/or Free Software criteria for Fedora] * Maintainer. Does the package have an active maintainer (somebody who can be expected to respond to inquiries and accept trivial patches within a reasonable amount of time)? Has a maintainer stated the intent to maintain the package for the Fedora project (regardless of whether the sources are maintained or not)? If so, has the maintainer agreed to the Fedora contribution guidelines? Is the package maintainer a principal developer of the source code? Finally, is the maintainer a Red Hat employee or contractor? [Meets Innovation and Quality criteria for Fedora] * Developer Resources. What is the definitive repository for the source code? What is the definitive Fedora specfile for the RPM, where is it maintained, and who maintains it? What do the major RPM distribution sites list as the definitive distribution source of the RPM (i.e., the source to other mirror sites)? What is the bug repository (ideally some bugzilla somewhere) for source code/project this package represents? What are the key developer mailing lists for this project (which maintainers are expected/known to read)? What resources and commitments exist for integration testing? [Meets Community and Quality criteria for Fedora] * Version numbering, compatibility and dependencies. What version numbers of the RPM should be consistent with which versions of which Fedora collections? [Meets Integration and Packaging criteria for Fedora] Orthogonal to the packaging are the people: * Committees. What is the charter of the committee? How constituted? How governed? What authority? What responsibilities? [Meets Accountability criteria for Fedora] * Inputs. What are key considerations identified by various Fedora Committees that would weigh one or more of these properties more or less heavily when considering the Fedora Collection Principles? [Grass catcher, sanity-check, arbiter] All of this leads to: * Collections. What collections are defined and what RPM packages belong to what collections? [Meets Community Utility and Ubiquity goals for Fedora] Proposed specifics for Package Classes Common Fedora collection guidelines are as follows: First, all packages destined for any Fedora colletion must meet, for our own protection and sanity, the following standards: Open source and/or Free Software Shippable from the USA Meets other applicable US law (dual use, gambling, patent) Not of an adult only nature Building rules to meet policy above Active maintenance and release of code Must keep record/inform us of cryptography uses CVS committers to have signed needed paperwork Changes should always be pushed upstream when possible Active involvement with upstream packages Upstream view strongly favoured in maintainer choices Does not cause gratuitous offence (including in other countries) [ie nazi deathcamp pacman is out, but non gratuitous stuff like alcohol related software shouldn't be] (?)We host build CVS for packaging not packages themselves normally Project maintains web pages in the standard format Project maintains a signing key securely and a web page for it Project page content has any required footers/header notices Project keeps any seperate content/discussion board etc on its own site and clearly distinguishable from the hosting pages With that out of the way, we describe a few of the many possible Fedora collections that may be built from packages meeting the above criteria: Fedora Live: an (as yet unsponsored) project to create a LiveCD based on Fedora Core technologies. These packages, burned onto a single bootable CD, have the remarkable property of being able to provide a credible subset of Fedora Core technologies for evaluation as well as the ability to bring a system up to a full Fedora Core system by issuing the appropriate command when connected to the Internet. Fedora Core: a moderate set of packages that balance the following criteria (many of which duplicate the above guidelines, but do so for ease of understanding): * meets open source and legal requirements * state-of-the-art, high-quality Linux distribution * completely self-hosting * preference for innovation over stability * preference for packages to be evaluated for future Enterprise Linux * preference for packages that maximize scope of Fedora Extras * preference for packages that satisfy most dependencies * preference to avoid packages that are highly specialized * preference to limit total packages to 3 CD ISO images Because virtually every Fedora user will install Fedora Core packages, these are the packages that will get the most testing, and hence provide the greatest information about what is, and what is not ready for inclusion into future versions of Enterprise Linux. Fedora Extras: the maximal universe of packages that * include all Fedora Core packages * meet open source and legal requirements * are 100% consistent with Fedora Core * are 100% consistent (not conflicting) with each other * preference for packages that are state-of-the-art * preference for packages that have strong community support Fedora Extras can be viewed as what Fedora Core would be if there were no limits on the number or size of packages. In reality, Fedora Extras will require some compromise between theoretical size (which could be over 10,000 packages) and practical size (based on how many packages can be integration tested within some reasonable time before and/or after the related Fedora Core release is frozen and released). Fedora Addons: packages that are consistent with Fedora Core, but not necessarily all of Fedora Extras. This might be the one place where OSS requirements are overlooked, in which case this may be the collection where binary-only packages find their home(s). But that remains to be debated (i.e., we may want to never confuse people about what "Fedora", in all its incarnations, means). Fedora Desktop: a subset of Fedora Extras that provide all useful Desktop applications (Web browser, Email client, Word Processor, Spreadsheet, Presentation Software, Image Editing and Viewing Software, etc). This subset may also be a subset, superset, or a non-proper superset of Fedora Core. * if needed, can be "upgraded" to Fedora Core via a network connection by issuing the appropriate command * preference to include packages needed to support a "managed" and "secure" desktop environment * preference to avoid other packages not likely useful to a "typical" desktop user * preference to limit total packages to a minimal number of CDs Fedora Desktop provides an opportunity to dismiss assumptions of Fedora Core for the purposes of finding a more minimal and/or more optimal set of packages for the "typical" desktop user. Fedora Alternatives and Fedora Legacy: defined externally. To first approximation, Fedora Alternatives are collections that meet OSS guideliness but do not meet Fedora Core and/or Fedora Extras compatibility requirements. Fedora Desktop is an example of a Fedora Alternative collection, targeted to Desktops. Fedora Legacy is a collection that's defined to meet OSS guidelines, but to have an update policy that favors maintainability over innovation (a non-goal of the mainstream Fedora project). Nothing in this charter is construed to prevent anybody from developing, distributing, downloading, or installing binary-only packages built for one or more Fedora collections. Of course, nothing in this charter overrides existing free and/or open source licenses nor the licensing terms of any binary-only packages, and thus if the license terms of the binary-only package conflict with one or more packages in a Fedora collection, it is the user's responsibility to prevent that conflict from occurring, or to remedy that conflict if/when it arises. Proposed Specifics for Fedora Committees This is something everybody's been waiting for. Without arguing right or wrong, but rather starting with the position of codifying existing practices: The Fedora Board: the group of people, many from Red Hat, who charter, uphold, and modify the constitutional principles of the Fedora Project. This board forms the Ultimate Authority to whatever extent possible across all Fedora activities, announcements, policies, processes, etc. It would take a pretty serious breech for the Fedora Board to step into the affairs of any other Fedora Committee, but if need be, it will. The Fedora Collection Committees: Each Fedora Collection shall have a Committee that defines the principles and processes of the Collection. What is the goal of the Collection? What commitments can people expect the Collection to uphold? How will packages be judged in or not in the Collection? What is the decision process? What is the appeals process? How are people added to or removed from the Committee? Thus, in principle, each Collection is self-governing, but when collections are defined in terms of other collections (like Fedora Extras is defined in terms of Fedora Core), the policies of "deeper" Collections take precedence over Collections built upon those Collections. The Fedora Core Committee is a special Committee defined by Red Hat. The principles of what comprise the Fedora Core Collection are articulated above in this strawman, and Red Hat retains arbitration authority on what's in or not in a Fedora Core Collection. Be that as it may, the Fedora Core Committee is not meant to be exclusively Red Hat. I'm open to discussions on how many of what sort of people we would want to have to round out this (or any other) Committee. Summary The purpose of this strawman is to pull back from the many different concerns being voiced on fedora-devel, to try to put these many issues into a common context that can be expanded, properly separated, and ultimately ratified by the community. Where details are sketchy, feel free to expand and/or rewrite. Where details are wrong, right them.
