THIS CONTRACT IS TO CLARIFY THE WORK, THE RIGHTS AND THE ACCESS THE ABOVE PARTNERS RECEIVE TO ANY ASPECT OF BITSTREAM SOFTWARE. YOU MUST READ THIS CONTRACT CAREFULLY AND SIGN IF YOU AGREE. IF YOU DO NOT AMENDMENTS CAN BE MADE, BUT ONLY BEFORE YOU SIGN. BOTH PARTNERS, MUST SIGN AT THE BOTTOM OF THIS CONTRACT TO AGREE TO EVERYTHING THAT HAS BEEN COVERED. IF THERE ARE ANY ASPECTS THAT ARE NOT COVERED WITHIN THIS CONTRACT EVEN AFTER BOTH PARTNERS HAVE SIGNED, SHEETS SHOULD BE ATTACHED TO THE BACK OF ALL THE COPIES OF THE CONTRACT AND ANY NEW SHEETS ARE SIGNED FOR SEPARATELY. ANY AMENDMENT SHEETS SHOULD NOT CONTRADICT ANY PART OF THE ORIGINAL CONTRACT AND SHOULD ONLY ADD TO THE CONTRACT. ANY AMENDMENT SHEETS WILL AUTOMATICALLY CLAIM THE SAME EXPIRY DATE AS THE ORIGINAL CONTRACT. EXPIRY DATES ARE AT THE BOTTOM OF THE SHEET AND MUST BE ALSO AGREED TO. AFTER THE FINAL PRINT OF THIS CONTRACT IS MADE AND SIGNED FOR, TO AGREE TO EVERYTHING STATED THEN A COPY SHOULD BE HELD EXTERNALLY AND COMPLETELY AWAY FROM BOTH PARTNERS (This can be in electronic form) . ANY AMENDMENT SHEETS SHOULD BE STORED WITH AND ATTACHED TO THE ORIGINAL CONTRACT IF IT HAS BEEN SIGNED BY BOTH PARTNERS.

To look after all the visual aspects of Bitstream Software, with some exceptions covered later. To maintain support and manitain the website.

Keep logs of statistics for research purposes.

Give technical Support to customers, referring to the programmer if needed.

Innovation for the main face of Bitstream and to create a good customer base.

Keep backward compatibility where possible.

Fix any errors reported.

To develop the software from start to end.

To keep track of customer technical support problems for future reference

To ensure beta versions of and software are made during the development process.

Search for source code.

Receive and respond to bug/beta reports with fixes.

Both the programmer and visual developer should correspond to make the whole process work, but there’s a point where one of the partner’s needs the last say, or ultimate control over their aspect. Later on the contract will declare who has access to what and who has the last say on every aspect of Bitstream Software. The general definitions for the jobs above just clear any misconceptions about the orientation of each partner’s work. It is just a guide, it is not the contract, it is part of the contract.

1. Website

2. Software Development

3. General Procedures

4. Customer Correspondence

5. Technical Support

6. Financial

1. Website 

   The Visual Developer has entire access to the website and must be the only one with access to it, this is a major separation between the jobs of both partners. The Visual Developer must be the only one in the world with access to the website and should only ever disclose the password to the Programmer in the following circumstances at the Visual Developer’s discretion :

   When files the programmer has on his computer need to be uploaded to the website, the password needs to be changed again after the files have been uploaded. The programmer will never expect access to the web sever after this occurrence until the occurrence happens again.

   When the Visual Developer goes away for a reasonable length of time. E.g. Two weeks, this again is at the discretion of the Visual Developer. The programmer will not expect this either.

   When circumstances dictate that the password should be given to the programmer, E.g. The Visual Developer leaves and literally wants nothing more to do with any of Bitstream, but this is at the discretion of the Visual Developer.

   The Visual Developer has complete control over the website, but must obey these rules : If there is any content that directly refers to persons living in the world then the Visual Developer should ask the person concerned to clear the content with the person before the page is published. Any changes that the person concerned requests should be obeyed so long as the person concerned requests are reasonable. If they are not the Visual Developer must refrain from publishing the page (s) until there has been a compromise with the person concerned. If no compromise is met about a specific piece of content then the page (s) should not be published at all. This only refers to persons living. A disclaimer should be made for the website in due course.

   The Visual Developer should listen to the people who talk to him that recommend solutions to potential or real problems that are in the website area. E.g. If there was a problem with a redirection URL put into a page and someone reports it, then the Visual Developer should correct this problem at the most convenient time wherever possible.

   The Visual Developer maintains the site with any new developments for the customer’s information. The Programmer’s knowledge of programming may sometimes mean he would have to write a page for the website, but if the programmer did this, it should be asked for explicitly by the Visual Developer, or suggested by the programmer if necessary. The programmer may also suggest to the Visual Developer certain ways in which he’d like to see the pages that he’s written come across. The Visual Developer has the power to include or exclude a page that the programmer has written, but not edit it, the Visual Developer should request the programmer write it again, or amend it. The Visual Developer should try to explain what changes should be made to make a compromization. The Visual Developer may only edit a page that the programmer has made in the way of spelling corrections or grammar correction, but not re-formatting or manipulation. This protects the programmer to make sure that the information on the page he’s written is correct. Often the pages that the programmer would ever write would be technical support pages. If the Visual Developer did not want a page on the website that the programmer had made then he would have the right to ask for the specific information from the programmer so as the Visual Developer can actually make the page himself. As long as the points that the programmer has made come across correctly in the page that the Visual Developer has written then the programmer has no right to change the content.

   Graphics on the website should be administered by the Visual Developer, except when a graphic refers to a living person. In which case the person concerned should have the right to have the graphic removed or changed.

2. Software Development

   The programmer (or software developer) has entire access to the source code of any software HE has developed for Bitstream Software. He has the absolute right to change features in the software, manipulate the code for any software and to develop it how he sees fit. Software Development includes both the interface of the software and the code behind the software, they are not split apart in any part of the process. The programmer must send the Visual Developer the source code for any application made for Bitstream Software at the end of any development period. This does not include beta versions. The programmer should ensure that the Visual Developer has enough information about the software to carry out his work on the website, for customer support and technical support pages. Documentation should be sent to the Visual Developer at the end of any development period. It should specify the exact syntaxes for any files that should be present on the server and explain how the internal software processing works in the simplest form to ensure he can update any files as he sees fit without any problem within the software. The Visual Developer maintains the right to change any files on the server though, even if they are software specific, if changes are made to any of these files the programmer must be informed and if any problem occur due to these changes the Visual Developer should (does not have to) act to make sure the problem is resolved. A problem might be with the syntax of the information in a file that the software processes from the server. The programmer maintains the right to develop all software for Bitstream with the help of the Visual Developer, or to have software to be reviewed by him if the Visual Developer starts making software. The programmer can often solve problems in source code if the Visual Developer specifies what he wants and where any problems may lie. The programmer has the right to keep a copy of the source code of any software made for Bitstream and has the power to reject software or request changes from the Visual Developer. This will avoid common bugs and enhance the knowledge of programming the Visual Developer has. The Visual Developer must submit software to the programmer before distribution from the website or any other website, when the software is under the name "Bitstream Software", whereas if the software is not under the company name then it is considered personal and cannot be included on the company website. The programmer has the right to change the interface and manipulate the interface as he sees fit, but the interface should be reviewed by the Visual Developer before the release and changed where necessary. The programmer has the right then to change the interface still, the last say on the interface is the programmer’s. The programmer must also accept that he should accept and incorporate the talents on the visual side of the Visual Developer. The programmer is required to inform the Visual Developer of any changes he makes to the interface. The Visual Developer has the right to ask for the source code back to solve any problems the programmer comes up with. The programmer does not have to inform the Visual Developer of interface changes when it is a small manipulation that is almost insignificant.

   Graphics in the software however are entirely up to the Visual Developer, the Visual Developer has the last say on that. BUT : The programmer can request further work on a graphic or ask questions about a graphic. The Visual Developer must listen to the programmer if he comes up with an idea different to the Visual Developer’s. The Visual Developer should try to come up with a compromization that suits both the programmer and the Visual Developer, but the programmer can only suggest solutions, he cannot enforce them where graphics are concerned. The programmer has the right however to include any of his graphics in the software when : He needs a graphic to work with on the interface so as to complete a development stage. In this case the programmer must also inform the Visual Developer when he thinks a graphic may be needed in the specific place permanently.

   OR :He can experiment with his own graphics and can try to bring across his ideas for the graphics in the final piece in beta versions. The Visual Developer however must have the final decision on what the graphical content actually is for the final release.

3. General Procedures

In this part of the contract clarification is made about general procedures that must be followed when situations that are not really to do with the company’s products or public interfaces.

• Resignation

This is the procedure that must be followed when one of the staff wish to leave the company.

The request to resign must be made at least two weeks before the member of staff wishes to actually have left. The request to resign must give a reason for the resignation and state when the member would like to end their job (not before two weeks from the first resignation e-mail) . At first the resignation should be noted and treated as a invalid. If the request for resignation comes three times on different days then this is an official resignation, but if the request comes once and the following day there is no talk of resignation then the first resignation should be scrapped. Only take resignations seriously when the request has come at least 3 times all on different days. The request can be cancelled at any time during the first two weeks from when the first request for resignation was made. Resignations should be treated with the utmost care as catering for unstable people is imperative. To clear it a little more : To leave you send an e-mail to the other partner or one of the partners requesting it. Then you send the request again in the following day and again the following day. This is then treated as official. If you leave a day in-between sending three requests then it is classified as invalid and you must start the resignation process again. To cancel the resignation during the first two weeks of the resignation declaration you must specifically ask for the resignation to be cancelled. Although preparation for the resignation may be already begun. You cannot get out of the company in less than two weeks now.

• Resignation between the partners 

The same applies above, only the partner should get paid still until the product being sold is no longer in any way related to the one that quit. In other words the application being sold should be updated before the programmer doesn’t get money. Or if the Visual Developer leaves then the website should no longer be related to him. So the works should be changed completely of the one that quit before the one that quit doesn’t get paid. This subject will be covered fully in the new contract after this has expired. It is a good idea to do loads of work for the company so your works are harder to replace so you get paid for longer.

• Death of Partner

In the event that one of the partners dies then all the work from the dead partner should be given to the other partner and he should carry on as normal.

• Contract Violation

Violating the contract is an offense to the Bitstream Software Principles Act 1998. You should never do this.

1. Customer Correspondence & Technical Support

   Customer correspondence should be primarily the Visual Developer's job, as he maintains access rights to the mail servers. The Visual Developer automatically takes on this responsibility because he has the access rights as specifies earlier in this contract. Although this may be the case, the Visual Developer can request assistance from the programmer if he feels it's necessary. The programmer has equal responsibility to actually respond to any customer correspondence that has been passed through Visual Developer to him. These occasions will often be a technical support question that the Visual Developer has not become acquainted with and so cannot help the customer without referring to the programmer. The Visual Developer also has the right to pass on all technical support questions to the programmer. This may be done through an automated system with the Visual Developer, or the Visual Developer may request that the programmer is to collect technical support mail from a server, located and set up by the Visual Developer or programmer. If a new server is set up for technical support the password for the server belongs to the programmer.

   A customer services question sent to any server accessible by the Visual Developer should normally be handled by the Visual Developer.

2. Technical Support

   Technical Support should be primarily handled by the programmer, he is required to keep a log of the reports to streamline technical support for the future. If the Visual Developer receives technical support problems then any mail such as this must be forwarded to the programmer for the records he is required to keep. In any forwarded mail such as this the Visual Developer must specify whether he has managed to respond to the problem, or whether he needs to entirely pass on the problem to the programmer. The Visual Developer may do this.

3. Financial

The financial aspects of Bitstream Software include:

• Access to the Register Now! Account.

• Banking issues

• Access to the PO box.

• Customer Database

• Registration Codes

• Access to the Register now account can be dealt with by both the programmer and the Visual Developer. This contract was made to extinguish such a situation, but as this is not a controllable area and is not a threat to Bitstream Software's integrity then the contract assumes that double access will not be a problem within the company.

• Banking will also be handled by both the programmer and the Visual Developer as to signatures are required to withdraw money and it is not a threat to let one of the partners pay in money behind the other one's back.

• Access to the PO Box will be handled by both partners, Cheques can be retrieved by either partner, but it should be agreed between the partners as to when they'd both like to pick up any content from the PO box. That is not a contractual agreement due to impracticalities.

• All customers should be logged into a database by both the programmer and Visual Developer. This is an absolute necessary arrangement that should be met by the partners privately.

• Registration codes will be handled by both the programmer and Visual Developer, but routines should be in place to stop duplicate registration code e-mails.

This is a contractual agreement that should be signed by both partners. It is an offense to break the contract.

This contract expires on the:

24^th June 1999

Additions shoud be signed and attached