[eros-cvs] cvs commit: eros/src/doc/www/faq avail.html
shap@eros.cs.jhu.edu
shap@eros.cs.jhu.edu
Mon, 20 Aug 2001 18:02:38 -0400
shap 01/08/20 18:02:38
Modified: src/doc/www/faq avail.html
Log:
Update description of availability terms
Revision Changes Path
1.9 +122 -71 eros/src/doc/www/faq/avail.html
Index: avail.html
===================================================================
RCS file: /cvs/eros/src/doc/www/faq/avail.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- avail.html 1999/10/22 01:08:53 1.8
+++ avail.html 2001/08/20 22:02:38 1.9
@@ -109,79 +109,130 @@
terms of use?</a></b>
</p>
<p>
- EROS is <em>not</em> free software. EROS is being made
- widely available for personal, research, and certain
- non-profit use. All such use must be non-commercial. It
- will also be made available under reasonable licensing terms
- for commercial use.
+ <em>Heartfelt thanks to Robin Lee Powell for reminding me to
+ update this section!</em>
</p>
<p>
- Draft versions of the license agreements can be found <a
- href="../legal/license/GPL.html">here</a>. The draft
- licenses are an attempt to compromise between making the
- system widely available and not losing my shirt. These
- drafts can be taken as a reasonable indication of intent,
- but please note that they are not yet final.
- </p>
- <p>
- Many people seem to have the idea that EROS should be given
- away in the style of Linux or the various BSD-like systems.
- These people are entitled to their opinions. I do not share
- them.
- </p>
- <p>
- I have put a large amount of effort and my own money into
- this project -- teetering on seven figures, when last I sat
- down to calculate it. I have absolutely no sympathy for the
- idea that writing a few hundred lines of driver code should
- give you the right to free use of this work, so please don't
- delay the release by trying to convince me with an argument
- of this form.
- </p>
- <p>
- If you build a good driver, I'll gladly incorporate it into
- the system and redistribute it for you. If you want that
- driver to have the BSD copyright so that others can derive
- from it, that is fine. For the present, I am not
- incorporating GNU-copyrighted materials into the core
- system.
- </p>
- <p>
- <em>How about Open Source?</em>
- </p>
- <p>
- It may prove, in the end, that the Open Source model is the
- best way to advance a commercial EROS effort. We are
- tentatively leaning that way. If so, that decision will be
- taken as a strategic marketing choice. When the time comes
- to make that decision, we'll solicit input from the
- community. Please don't distract us from getting the
- release out by pressing the matter now.
- </p>
- <p>
- If we do go the Open Source route, we will do so with at
- least one modification:
- </p>
- <p>
- Because EROS is a secure system, there needs to be a central
- source that ``vets'' and ``brands'' the distribution. When
- somebody asks ``secure according to whom?'' There needs to
- be an answer. Also, people need to know if they are running
- the vetted version or some modification of that.
- </p>
- <p>
- This means that we will be fairly strict about the use of
- the name ``EROS.'' If you distribute a modified system, you
- will be able to call it ``EROS derived,'' but you will not
- be able to call it ``EROS.'' The official release will also
- be digitally signed or one-way hashed so that users can
- verify its authenticity.
- </p>
- <p>
- The implications of this issue have not yet been thought
- out. As I said before, we will solicit input at the
- appropriate time.
- </p>
+ EROS is available under the GNU General Public License (GPL)
+ and the GNU Lesser General Public License (LGPL). A detailed
+ description of the licensing terms may be found on the <a
+ href="../legal/terms.html">Distribution Terms</a> page.
+ Extensive discussion of (L)GPL license and what it means may
+ be found at the <a href="http://www.fsf.org">Free Software
+ Foundation</a> web site.
+ </p>
+ <p>
+ Because EROS is a component-based system, it does not rely as
+ heavily on linking as conventional systems. Given this,
+ applying the ``work based on the program rule of GPL is not
+ always easy to understand. The terms page gives some
+ guidelines for when a newly introduced component must be
+ distributed under GPL. The rules are a work in progress. The
+ current set has two purposes:
+ </p>
+ <ul>
+ <li>
+ <p>
+ They try to preserve the ``freely available'' character
+ of the EROS system by preventing modifications that
+ would render critical portions of the system
+ proprietary.
+ </p>
+ </li>
+ <li>
+ <p>
+ They try to protect the security of the system by
+ requiring that security-critical components be made
+ public.
+ </p>
+ </li>
+ </ul>
+ <p>
+ Earlier releases of EROS were made available under more
+ restrictive licenses. Now that this is a thing of the past,
+ I can admit the real reason for it: EROS wasn't ready for
+ other people to play yet.
+ </p>
+ <p>
+ Successful open source efforts seem to follow a couple of
+ rules. One of these rules is that they begin with some
+ critical mass of cohesive software that serves as a template
+ that a community can react on. In the course of building
+ the original EROS system, it became clear that another major
+ round of work on the kernel would be required. Since getting
+ my dissertation done was also a priority, I crafted a
+ license that would allow people to start getting a sense of
+ the system <em>without</em> creating a large user base that
+ would require care and feeding.
+ </p>
+ <p>
+ We also had concerns about security and provenance
+ management, which is the next topic.
+ </p>
+ <p>
+ <em>Concerns About Open Source</em>
+ </p>
+ <p>
+ Open source raises a concern in the context of secure
+ systems: how can a recipient have confidence that they have
+ received a trustworthy system?
+ </p>
+ <p>
+ In the context of secure systems, the great strength of open
+ source is also its greatest weakness: anyone can modify the
+ code. In order for a non-technical user to safely use such a
+ system, they need to have some <em>assurance</em> that what
+ they receive is secure.
+ </p>
+ <p>
+ For engineers, ``assurance'' is an uncomfortable word. While
+ assurance processes help produce better systems, assurance
+ is not really about whether a system is correct; it is about
+ whether a customer can have <em>confidence</em> that a
+ system is correct. An oft-quoted open source mantra: ``read
+ the source,'' is not helpful to typical users. Most users
+ lack the necessary expertise to productively read source
+ code. But even if they could, there is a more subtle
+ problem: <em>which</em> source?
+ </p>
+ <p>
+ Because the customer cannot read the source, the problem of
+ confidence must be broken down into two pieces:
+ </p>
+ <ul>
+ <li>
+ <p>
+ Somebody needs to choose a set of sources, read them (or
+ more broadly, apply appropriate assurance processes),
+ and package them for redistribution. This assurance
+ activity is a <em>service</em> provided to the end
+ customer. It may or may not be backed by a guarantee,
+ and the guarantee may or may not have financial
+ ``compensation'' (a.k.a. insurance) associated with it.
+ </p>
+ </li>
+ <li>
+ <p>
+ Both the customer and the provider need a way to agree
+ that the system the customer received is in fact the
+ system that the provider assured.
+ </p>
+ </li>
+ </ul>
+ <p>
+ It took a while to figure out how to ensure all of this in
+ an open source model. In the end, the key proved to be
+ simple: branding. We will be fairly aggressive about
+ protecting whatever name the system is ultimately assured
+ under. Actually, we will need to use separate brands: one
+ for the system and the second for the assured version. The
+ official release will also be digitally signed or one-way
+ hashed so that users can verify its authenticity.
+ </p>
+ <p>
+ Others, of course, can independently assure versions of the
+ system under their own brands.
+ </p>
</li>
<li>
<p>