This section contains the major software licenses used in the project, either for application source code, documentation, or any other file contained in the system. The choices of these licenses are explained in the next section of this document. The terms of this license are extracted from the "Open Source Definition", thus it should be compatible with the original terms. DeforaOS project licensing terms -------------------------------- Preamble -------- "the author" in this license is myself, Pierre Pronchery. Introduction ------------ The use of the software distributed as part of the DeforaOS project must comply with the following criteria. The concerned software includes at least the following (unless explicitly mentionned by the author): - every software contained in the project "DeforaOS". - every software distributed on the DeforaOS project website, "http://www.defora.org/", belonging to the author. 1. Free Redistribution ---------------------- Anyone is free to sell or give away the software, as a component of an aggregate software distribution containing programs from several different sources. Not royalty or any fee is required to do this. 2. Source Code -------------- Distribution of the software is allowed in source code as well as compiled form. Where some form of the product is not distributed with source code, there must be a well-publicized means of obtaining the source code, not exceeding the cost of an average internet download. The preferred form of modification is of source code, via the unified diff format. It is not allowed to obfuscate source code in any way, or to use any intermediate compilation format. 3. Derived Works ---------------- Modifications and derived works are tolerated. They must be distributed according to the terms of this license. Moreover, the author kindly asks anyone working on such modifications or works to keep him informed of these. The aim is to let them benefit to everyone, and keep the best version of the software, and related works, available at the original place (as a matter of global coherence, and ease of use). 4. Integrity Of The Author's Source Code ---------------------------------------- Any modification of the source code, must be distributed as patch files, according to the unified diff format. Distribution of software built from modified source code is allowed. Derived works must carry the same name, and must modify the version number this way: "original.version.number-vendor_name". 5. No Discrimination Against Persons Or Groups ---------------------------------------------- This license doesn't discriminate against any person or group of persons. 6. No Discrimination Against Fields Of Endeavor ----------------------------------------------- This license does not restrict anyone from making use of the software in a specific field of endeavor. 7. Distribution Of License -------------------------- The rights attached to the software apply to all to whom the software is redistributed, without the need for execution of an additional license by those parties. 8. License Must Not Be Specific To A Product -------------------------------------------- The rights attached to the program do not depend of any other licensing rights. 9. License Must Not Restrict Other Software ------------------------------------------- This license does not place restrictions on other software that is distributed along with the licensed software. 10. License Must Be Technology-Neutral -------------------------------------- No provision of the license may be predicated on any individual technology or style or interface. The license for the documentation will certainly be more restrictive. It is currently: any public documentation written about the project has to be submitted for approval to the project developpers; anyone may write and submit documentation; public documentation may be used freely as long as it remains synchronized and unmodified from the one on the project website, and it contains at least one link, on the frontmatter, pointing to the address of the official version on the project website. License terms for other kind of files used in the project are licensed individually. The philosophy carried with the project licenses is to give as much freedom as possible to its users. They are basically allowed to use, distribute, and study without permission the concerned software. Two important points are mentioned though: modifications should be submitted to the current authors of the project, so that they can benefit to everyone; consequently, forks of concerned software, contained in this project, should not be started (so that development efforts can be shared as much as possible). These points are not absolutely mandatory because I am convinced that the free (as of freedom) software development model is the best, even if as a software author I can't guarantee that I'll get rewarded for my work. In case of abuse of concerned software, I will certainly change this project license terms. Of course I am not supporting free software without a reason. There are even many actually, which I can sum up here: interoperability: availability of the source code, transparency of the development process, and whenever possible strict adherence to the standards guarantee the users that they will be able to work even in heterogeneous environments; security: availability of the source code guarantees that the software is exempt of intentional malicious code, and is possibly being used or auditable by competent persons; perennity: availability of the source code guarantees that the software can be supported by third-party organisms at any time, and in a fair competition environment; independance: the project is not related in any way to any software or hardware vendor, even though donations can be accepted (and improve hardware support for instance) the project decisions will not be influenced this way. Not everything is perfect though, there is one point I sometimes have to deal with, the global coherence of open-source projects. Of course they are not initially designed for a single platform, and it's the duty of software distributors to adapt them to their own environment. That's where I think there is a place for big improvement. I feel the need of a complete platform project, fully open source and autonomous. And even then, remaining coherent certainly requires a tight team, most probably as small as possible. There are many UNIX systems developped and used worldwide. This OS design had proved to be very robust and is still considered as modern while it is more than 20 years old. Technically superior to most other systems, it is supported and more and more developped by the free software community, in its near entirety. A bug issue with UNIX is that there are as many different conceptions of the system as there are UNIX implementations and distribution. Both the developper and user suffer from inconsistency between these implementations, though it happens that they share a lot of high level software. There are even often not too many different implementations of major applications, which are also often among the best cross platform applications in their field. UNIX carries simple concepts of every part of the system. It has light and flexible historical inheritances within more than 30 years (some are more painful than others). It also provides a sophisticated yet flexible and clear setup, appropriate software versions handling, localization ease. It present things like they actually are, which fits experienced users and helps beginners. It allows very different development models, including open source bazaar. Windows is the product of one company, which happens to have a very strong market share of critical fiels of computer software. Few versions of Windows exist, and they are nearly fully compatible with each other. However the big market share has attracted a huge part of software development efforts on this platform, often gaining money from its design and implementations flaws. Consequently there are often many different major applications in every field, which often provide poor support, for they have commercial and proprietary development model, and often get bought by each other, or even disappear or simply drop support. Windows often carries very complex conceptions of an operating system, which are often badly documented, and of course won't be available in source code unless you pay or have any other kind of power. In consequence many applications are written the bad way, get famous and so must work on every different Windows, and so carry the system bugs forever. This leads to awful historical inheritances while the system is about 10 years old, and chaos deep inside the system (DLL conflicts, registry mess, localization issues, ...). The company wants its software to be accessible to any user, so many technical and original terms get renamed and appropriated, as a way to stuck and fool the user to the platform. On the other side, experienced users keep being frustrated, particularly where the development roadmap is so obfuscated and subject to contradictory decisions (eg MFC vs .net WinForms vs XAML). The most revealing company behaviour, even more than the FUD (fear, uncertainty, doubt) spread against its competitors, is the embrace and extend gluttony. The company uses aggressive standards conformance where it does not yet dominate a market, then buys the major actors in the given area, and then uses proprietary protocols and stops development of the product. There aren't many other systems for the average end user or low scale servers. Even Apple's operating system is now an UNIX. FIXME: always think like the users, and listen to them... FIXME: a few words, and conceptual screen shots, about it would feel like to use the system... The system will boot with a minimal filesystem image in memory, mounting the system directory from a location hard-coded in the image, or a bootloader parameter. Additional volumes will be directly available in the volumes hierarchy, and eventually mapped to the user defined applications and data files hierarchies. They actually are applications engines, with the appropriate memory mappings and other priviledges necessary in their very purpose. Applications using the drivers connect to them like interfaces usually do. Interface proxy to the filesystems drivers. Knows the filesystems mappings. Maintains the pid/fd mappings. Only interface allowed to connect to the filesystems drivers. Sanitizes all accesses (handles and removes special path like ".", "..", etc). First, I want to avoid as much as possible to use assembly code. This is for obvious portability and readability reasons. I believe the micro-kernel should be coded in both assembly and C, because it has to be written with the computer limits and inner workings in mind. Object abstraction (in the programming language) is not necessary in the case of the kernel to my mind. I am also thinking about using C in the whole base system: Ada: no; it could be very interesting, but not close enough to the hardware; Assembly: no, long to write, too close to the machine; C: yes, simpler to implement (and kind of mandatory anyway), few keywords, total liberty in APIs definitions, even if lacks exceptions, and is too close to the assembly language (then again we can handle the machine limits, ...if we think each time about each possibility) C++: no, bloat, hell to implement; C#: no, I still have to look better at it; D: no, doesn't look mature yet; Haskell: no, I am not convinced by functional languages here; Java: no (virtual machine, verbosity of the language, classes names, ...); Objective C: no, though certainly interesting, but I find the syntax cryptic; Perl: no, interpreted; Python: no, interpreted; And also, as I care about coherence, the APIs in every language will be directly derived from a common definition, up to the point that every language would stick to its syntax, but could be compiled and linked against objects written in another one. If this is possible of course. Everything helping portability and interoperability will be appreciated, even though coherence in between languages supported by the platform is the primary objective. Every application runs inside what's called a "session". They are split in two parts: the application "engine", and the "interface". The end-user interaction should be presented the same way in text mode or graphical mode, possibly via the same API, and using only one binary for both. The session program manages the applications running. It may start some automatically upon startup, or scheduled tasks, and remember its state upon close for next start. It keeps listening to the state of its child applications, possibly reacting to their behaviour (excessive resources usage, abnormal termination, ...). It is also in charge of interaction between the applications engines and interfaces, and knows where to call or deport a call between engines (eg open an internet browser window on local engine, open an IRC engine application always on a distant server, ...). It can be considered as an applications engines directory. Application engines actually do their job, and keep their state, without handling any end-user interaction (but this doesn't prevent them to log messages for instance). Application interfaces are dedicated to the rendering and interaction with an application engine state. Ideally a given interface would propose identically either graphical, and text-mode graphical versions of the interface (and optionally a text only). The applications interfaces may detect the requested toolkit to use according to the availability of an environment variable ("DISPLAY" for instance), or by the result of an equivalent to the istty() call. Some applications may work with character streams as a fallback, typically like the UNIX filtering applications. FIXME The graphics library would be fully OpenGL compliant. The clients will certainly communicate with the graphical server like an Application Interface. About the graphical toolkit for applications, I insist that only one library will be supported, and binary compatible with the text mode toolkit. It may be more efficient to implement the toolkit on the server side, this will be decided later too.