[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Definition of Open Source [was Re: pine: UW permission to distribute]



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 den ottolander nl) 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 redhat com
> 

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]