Document:

Ninth Joint Memorandum by Microsoft Corporation and the Registrant

 Exhibit 10.64 
 Confidential treatment has been requested for portions of this exhibit. The copy filed herewith omits the information subject to the confidentiality requested. Omissions are designated as [***]. A
complete version of this exhibit has been filed separately with the United States Securities and Exchange Commission. 
 January 25,
2010 
 Ninth Joint Memorandum by Microsoft Corporation (“Microsoft”) and Novell, Inc. (“Novell”) 

 

	 	Re:	Purchase of Additional SLES Subscriptions and Modified Discount 

 Background on Prior Joint Memoranda/Amendments: 
  

	 	•	 	 On November 2, 2006, Microsoft and Novell entered into a Business Collaboration Agreement (“Original BCA”). The Original BCA
defines the terms and conditions under which Novell will sell to Microsoft for distribution to prospective shared customers and other SUSE Linux Enterprise Server (“SLES”) licensees, the right to enroll in SLES support subscriptions
(“Prepaid Subscription Rights”). 

  

	 	•	 	 On December 28, 2006, the parties executed a Joint Memorandum (“BCA Amendment #1”) regarding participation by the parties’
respective Irish subsidiaries in the Original BCA. 

  

	 	•	 	 On January 16, 2007, the parties executed a First Amended and Restated Business Collaboration Agreement, superseding the Original BCA (such First
Amended and Restated Business Collaboration Agreement, the “BCA”). 

  

	 	•	 	 Also on January 16, 2007, the parties executed a Second Joint Memorandum (“BCA Amendment #2”) regarding the impact of a
January 16, 2007 participation agreement entered into between the parties’ respective Irish subsidiaries in the BCA. 

  

	 	•	 	 On May 1, 2007 the parties executed a Third Joint Memorandum (“BCA Amendment #3”) regarding certain expanded SLES Subscriptions
available under Prepaid Subscription Rights. 

  

	 	•	 	 On December 21, 2007, the parties executed a Fourth Joint Memorandum (“BCA Amendment #4”) regarding promotion of SLES licenses in
the Asia Pacific region. 

  

	 	•	 	 On January 17, 2008, the parties executed a Fifth Joint Memorandum (“BCA Amendment #5”) regarding the creation of SLES High
Performance Computing Subscriptions. 

  

	 	•	 	 On April 10, 2008, the parties executed a Sixth Joint Memorandum (“BCA Amendment #6”) regarding the territorial restrictions on
the Asia Pacific Commitment. 

  

	 	•	 	 On December 22, 2008, the parties executed a Seventh Joint Memorandum (“BCA Amendment #7”) regarding a modification of the
multi-year subscription and delivery schedule called for in the original BCA. 

  

	 	•	 	 On January 23, 2009, the parties executed an Eighth Join Memorandum (“BCA Amendment #8”) regarding Basic Subscription
Certificates to enable sales by NEC Corporation. 

  
 [*** Confidential Treatment
Requested] 
 Page 1 of 2 

 Amendment: 
 The parties agree to further amend the BCA as follows solely to enable the purchase and resale of additional SLES Subscription certificates. All capitalized terms not defined herein shall have the same
meaning as set forth in the BCA (as amended). 
  

	 	1.	Section 4.1. Section 4.1 of the BCA is amended by adding the sentence below at the end of the existing text: 

“Effective as of the date of this Amendment #9, Microsoft’s purchase price for the right to enroll in a single SLES Subscription
under the BCA shall equal [***] shall remain unchanged).” 
  

	 	2.	Section 4.2. Section 4.2 of the BCA is amended by adding the following new subsection 4.2(e): 

“(e) Microsoft will purchase from Novell [***] of additional Prepaid Subscription Rights (“Amendment #9 Purchase”).
Microsoft will pay Novell for such Amendment #9 Purchase no later than [***], and delivery of Subscription Certificates to Microsoft will be on an as-needed basis until the earlier of exhaustion of the Amendment #9 Purchase or [***]. If Microsoft is
unable to sell some or all of the Subscription Certificates purchased under this Amendment #9 by [***]. 
  

	 	3.	Effect. Except as expressly amended and supplemented by this BCA Amendment #9, the parties hereby ratify and confirm that terms and conditions of the BCA (as
amended) remain in full force and effect. 

  

	 	4.	Counterparts. This BCA Amendment #9 may be executed, each of which shall be deemed an original, but each together shall constitute one and the same instrument.
For purposes hereof, facsimile copy of this BCA, Amendment #9, including the signature pages hereto, shall be deemed to be an original. Notwithstanding the foregoing, the parties shall deliver original signature copies of this BCA Amendment #9 to
the other party as soon as practicable execution thereof. 

 Accepted and Agreed by Novell, Inc. 

 

			
	Signature:	 	 /s/ Ron Warren

			
	Printed Name:	 	 Ron Warren

			
	Title:	 	     Director, Contracts

	Date:	 	         01/25/10

Accepted and Agreed by Microsoft Corp. 
  

			
	Signature:	 	 /s/ Horacio Gutierrez

			
	Printed Name:	 	 Horacio Gutierrez

			
	Title:	 	 Corporate Vice President and Deputy

		 	 General Counsel

	Date:	 	     01/25/10

  
 [*** Confidential Treatment
Requested] 
 Page 2 of 2Statement of Work No. 2 under the Technical Collaboration Agreement

 Exhibit 10.65 
 Confidential treatment has been requested for portions of this exhibit. The copy filed herewith omits the information subject to the confidentiality requested. Omissions are designated as [***]. A
complete version of this exhibit has been filed separately with the United States Securities and Exchange Commission. 

Statement of Work No.2 
 This SOW2 is entered into by and between Microsoft and Novell on the SOW2 Effective Date under the TCA. 
  

	 	1.	PROJECT TITLE AND DESCRIPTION 

 

	 	(a)	Title. Directory and Identity Interoperability 

  

	 	(b)	Description. In this Additional Project, Novell will provide interoperability between the Current ADFS and Access Manager via WS-Federation, and between the
Current WCS and the Novell Products via ISIPvl.0. 

  

	 	2.	DEFINITIONS 

  

	 	(a)	“Microsoft” means Microsoft Corporation. 

  

	 	(b)	“Novell” means Novell, Inc. 

  

	 	(c)	“Additional Project” is defined in section 5.5 of the TCA. 

 

	 	(d)	“TCA” means the Technical Collaboration Agreement between the parties with an effective date as of November 2, 2006. 

(e) 
  

	 	(f)	“Current” means as of the SOW2 Effective Date. 

  

	 	(g)	“SOW2” means this Statement of Work No. 2. 

  

	 	(h)	“SOW2 Effective Date” means the first date by which both Parties have executed this SOW2. 

 

	 	(i)	“ADFS” means the Microsoft Active Directory Federation Services component of Windows Server 2003 R2. 

 

	 	(j)	“Access Manager” means a new version of, or update to a prior version of, Novell’s Access Manager product. 

 

	 	(k)	“WS-Federation” means, with respect to the WS-Federation specification identified at http://www.microsoft.com/interop/osp/default.mspx as it
existed on October 16, 2006 and any version of the specification resulting from further standardization efforts identified at http:www.oasis-open.org, the required portions of the specification that are described in detail and not merely
referenced therein, as well as the required elements of optional portions of the specification. “WCS” means Microsoft Windows CardSpace. 

  

	 	(l)	“Novell Products” and its variations means Access Manager and three (3) Selectors. 

 

	 	(m)	“Selector” and its variations means an information card selector reference implementation that implements ISIPv1.0. 

 

	 	(n)	“ISIPv1.0” means, with respect to the Identity Selector Interoperability Profile v1.0 specification identified at
http://www.microsoft.com/interop/osp/default.mspx as it existed on October 16, 2006 and any version of the specification resulting from further standardization efforts, the required portions of the specification that are described
in detail and not merely referenced therein, as well as the required elements of optional portions of the specification. “Acceptance Plan” means acceptance criteria for each of the Deliverables as described in Exhibit A.

  
 [*** Confidential Treatment
Requested] 
 Page 1 of 6 

  

	 	(o)	“Deliverables” means: 

  

	 	i.	Access Manager interoperating via WS-Federation With Current ADFS and via ISIPvl.0 with Current WCS, all as set forth in the Acceptance Plan, with a beta or final
version delivered by October 31, 2008. 

  

	 	ii.	 First, Second, and Third Selectors, accessible via C++, C”, and Java bindings, respectively, and interoperating via ISIPv1.0 with Current WCS, all as set forth in the
Acceptance Plan, at least one of which is available for openSUSE 10.3, at least one of which is available for SUSE Linux Enterprise Server 10, at least one of which is available for Mac OS X, at least one of which is available to Firefox via
a Plugin, and at least one of which is available to Safari via a Plugin, with the Selectors delivered by October 31, 2008. 

  

	 	iii.	The Firefox and Safari Plugins referenced above, delivered by [October 31,2008]. 

 

	 	(p)	“STS” means Security Token Service. 

  

	 	(q)	“Mac OS X” means Mac OS X version 10.5, known as “leopard”. 

 

	 	(r)	“Firefox” means Firefox 2. 

  

	 	(s)	“Safari” means Safari 3. 

  

	 	(t)	“Plugin” means a plug-in, add-in, add-on, or extension. 

  

	 	(u)	“Deliverables Acceptance Date” means the first date by which Microsoft has, or is deemed to have, accepted all the Deliverables.

  

	 	(v)	“Subcontractor” means a third party with whom Novell contracts on a work made for hire basis to meet Novell’s obligations under this SOW2 on
Novell’s behalf. 

  

	 	3.	PARTIES’ OBLIGATIONS 

 

	 	(a)	Novell Obligations. 

  

	 	i.	Provide interoperability for the Novell Products with Current WCS via ISIPv1.0 and for Access Manager with the Current ADFS via WS-Federation, all as set forth in the
Acceptance Plan. 

  

	 	ii.	Make available, at a time and in a manner determined by Novell, the Novell Products. 

 

	 	iii.	Demonstrate the Novell Products at one industry event to be mutually agreed upon between the parties and to occur after the SOW2 Effective Date.

  

	 	iv.	Publish, in connection with three Selectors, test scripts and test results from testing the Selectors against the Access Manager STS or the Higgins Project STS pursuant
to the Acceptance Plan. 

  

	 	v.	Deliver to Microsoft for review and acceptance or rejection according to the Acceptance Plan the Deliverables. 

 

	 	vi.	Within twenty-one (21) days following the SOW2 Effective Date, use reasonable commercial efforts to perform and demonstrate the uses cases set forth in section 3
of the Acceptance Plan, substituting the Active Directory Federation Services component of Windows Server 2008 in place of ADFS. 

  

	 	(b)	Microsoft Obligations. 

  

	 	i.	Review and accept or reject the Deliverables according to the Acceptance Plan. 

 

	 	ii.	Pay Novell as described below. 

  

	 	iii.	Provide, on an ongoing basis for the term of this SOW2, information reasonably requested by Novell to complete the work described herein. 

 

	 	iv.	Demonstrate the interoperability of Microsoft products with the Novell Products at the one industry event mutually agreed upon between the parties and occurring after
the SOW2 Effective Date, as referenced above. 

  

	 	4.	FEES 

  

	 	(a)	The cost incurred by Novell under this SOW2 is agreed by the parties to be [***] (“Fees”). 

  
 [*** Confidential Treatment
Requested] 
 Page 2 of 6 

	 	(b)	The Fees shall be invoiced according to the following milestone schedule: 

  

	 	i.	[***] 

  

	 	ii.	[***] 

  

	 	(c)	In both parties’ judgment, only [***] identified in Section 3.4(e) of the TCA is needed for the Optimization Innovation Laboratory. The parties mutually agree
that, pursuant to Section 5.5(e) of the TCA, [***] from Section 3.4(e) of the TCA [***] shall be applied to another TCA objective, namely, Additional Projects under Section 5.5 of the TCA. The parties further mutually agree that as a
result of such application, [***]. For clarity, payment of the Fees by Microsoft under this SOW2 [***] of the TCA for Additional Projects. 

  

	 	5.	ACCEPTANCE 

  

	 	(a)	Each Deliverable shall be accepted by Microsoft provided that such Deliverable meets the applicable acceptance criteria set forth in the Acceptance Plan.

  

	 	6.	TERM 

  

	 	(a)	The term of this SOW2 shall commence on the date on which Novell begins to perform the work, and shall end upon the later of Novell’s receipt of all Fees under the
Fees Section above and 90 days after the Deliverables Acceptance Date; provided however that sections 3.a.ii, 3.a.iii and 3.b.iv shall survive the term of this SOW2. 

 

	 	(b)	Under no circumstance will termination or expiration of this SOW2 result in termination or expiration of the TCA. 

 

	 	7.	OTHER 

  

	 	(a)	Novell has no obligation under this SOW2 to support or maintain the Novell Products. 

 

	 	(b)	[intentionally omitted] 

  

	 	(c)	Novell may contract with a Subcontractor on terms requiring the Subcontractor to comply with the applicable terms of this SOW2 and the TCA. 

 

	 	(d)	This SOW2 does not change the ownership of anything created, developed, provided, delivered, published, made available, or demonstrated hereunder, and under no
circumstances are the Deliverables hereunder works made for hire. 

  

	 	(e)	This SOW2 may be terminated by either party in the event that the other party has materially breached any term of this SOW2 upon receipt of written notice thereof if
the nonperformance or breach is incapable of cure, or upon the expiration of ten (10) days (or such additional cure period as the non-defaulting party may authorize) after receipt of written notice thereof if the nonperformance or breach is
capable of cure and has not been cured. 

  

	 	(f)	[***]. In addition, Novell may propose additional work deemed relevant to this Additional Project, and such work may be added to this SOW2 upon the mutual written
consent of the parties. 

  

									
		 	Novell, Inc.	 		 		 	Microsoft Corporation
					
	By:	 	 /s/ Jeff Jaffe
	 		 	By:	 	 /s/ William Laing

									
	Name:	 	 Jeff Jaffe
	 		 	Name:	 	 William Laing

									
	Title:	 	 CTO & EVP
	 		 	Title:	 	 CVP

									
	Date:	 	 9/28/08
	 		 	Date:	 	 9/30/08

  
 [*** Confidential Treatment
Requested] 
 Page 3 of 6 

 Exhibit A 
 Acceptance Plan 
  

	1.	Overview. This Acceptance Plan contains acceptance criteria for each of the Deliverables In SOW2. The criteria for Access Manager are set forth in section 3
hereof, and the criteria for the Selectors are set forth in section 4 hereof, and Microsoft’s obligation to accept a Deliverable shall be contingent upon the Deliverable meeting the criteria prescribed herein. 

 

	2.	Acceptance. Deliverables will be deemed satisfactory to and accepted by Microsoft unless within thirty (30) days after delivery, Microsoft gives Novell
written notice of aspects in which a Deliverable does not meet the SOW2 requirements. Upon receipt of such written notice, Novell will use commercially reasonable efforts to make such changes as will be required to correct any deficiencies.

  

	3.	Acceptance Criteria: Access Manager. Either via a face to-face meeting or an application sharing collaboration meeting over the Internet, the following use cases
will be demonstrated. 

  

	 	3.1	Use Case One (WCS): NIDP (Novell Identity Provider) acting as a relying party. In Use Case One, a user has a personal card and would like to use that card to
login to a system. The basic steps are: 

  

	 	3.1.1	The user requests access to a protected resource that requires a WCS Authentication contract at the access gateway. 

 

	 	3.1.2	The user is redirected to the NIDP for login. 

  

	 	3.1.3	The NIDP requests a card from the user. 

  

	 	3.1.4	A Selector prompts the user for which card to use, and the user picks a personal card. 

 

	 	3.1.5	If this is the first time the NIDP has seen this card, then the following are performed: 

 

	 	3.1.5.1	  The user is prompted for his or her username and password. 

  

	 	3.1.5.2	  The username and password are verified against a user store. 

  

	 	3.1.5.3	  The card information is saved in a trust store. 

  

	 	3.1.6	It this is not the first time the NIDP has seen this card, then the card is looked up in the trust store and the user is redirected back to the access gateway.

  

	 	3.1.7	The access gateway then uses any identity injection, authorization, or form fill policy with information either from the personal card or from the user store.

  

	 	3.1.8	The user is allowed access to the protected resource. 

  

	 	3.2	Use Case Two (WCS): NIDP acting as an identity provider. In Use Case Two, a user has a managed card issued from an identity provider, and a relying party is
requesting that this card be used for authentication. The basic steps are: 

  

	 	3.2.1	The user requests access to a protected resource that requires a WCS Authentication contract at the access gateway. 

 

	 	3.2.2	The user is redirected to the NIDP for login. 

  

	 	3.2.3	The relying party requests a managed card from the NIDP. 

  

	 	3.2.4	A Selector presents the user with a list of managed cards that will satisfy this request, prompts the user for which card to use, and the user picks a card.

  

	 	3.2.5	The Selector makes a request to the identity provider for authentication. 

  

	 	3.2.6	The username and password for the identity provider is requested. 

  

	 	3.2.7	The information from the managed card is given to the Selector, which passes it on to tile relying party. 

 

	 	3.2.8	The user is then authenticated based on the trust associated between the identity provider and the relying party. 

  
 [*** Confidential Treatment
Requested] 
 Page 4 of 6 

	 	3.2.9	The access gateway then uses the information on the managed card or from a federated user store to get information for Access Manager policies.

  

	 	3.3	Use Case Three (WCS): NIDP acting as a card issuer. In Use Case Three, an NIDP will be issuing a managed card to a user that can either be backed by a
username/password, or a personal card. The basic steps are: 

  

	 	3.3.1	The user logs into the NIDP. 

  

	 	3.3.2	The user goes to a page on the NIDP’s portal. 

  

	 	3.3.3	The user requests the creation of a managed card. 

  

	 	3.3.4	The user is asked if he or she wants to back the managed card with a personal card. 

 

	 	3.3.5	If the user chooses to back the managed card with a personal card: 

  

	 	3.3.5.1	  The NIDP requests the personal card. 

  

	 	3.3.5.2	  A Selector asks the user to select the personal card, or to create a new personal card. 

 

	 	3.3.5.3	  The Selector sends the selected or created personal card to the NIDP. 

 

	 	3.3.6	The user is given a managed card. 

  

	 	3.4	Use Case Four (ADFS): NIDP providing authentication to a resource protected by Active Directory Federation Services. In Use Case Four, a user needs access to a
resource that is protected by Active Directory Federation Services. The basic steps are: 

  

	 	3.4.1	The user requests access to the resource. 

  

	 	3.4.2	The resource asks for authentication by Active Directory Federation Services. 

 

	 	3.4.3	An Active Directory Federation Services server is setup to know about an NIDP and gives the user the option of logging in at the NIDP. 

 

	 	3.4.4	The user logs into the NIDP and is provided a token that is sent to the Active Directory Federation Services server and satisfies the request of the resource.

  

	 	3.4.5	The user is allowed to access the resource. 

  

	 	3.5	Use Case Five (ADFS): Active Directory Federation Services providing authentication to a resource protected by NIDP. In Use Case Five, a user needs access to a
resource that is protected by NIDP. The basic steps are the same as Use Case 4 with AD FS and NIDP switching places. 

  

	4.	Acceptance Criteria: Selectors. The following will be demonstrated for the Selectors: 

 

	 	4.1	Source Code. A reference to source code for: 

  

	 	4.1.1	 A Selector available for openSUSE 10.3 interoperating via ISIPv1.0 with the GetToken functionality of Current WCS and accessible via C++ bindings. 

 

	 	4.1.2	 A Selector available for Mac OS X interoperating via ISIPv1.0 with the GetToken functionality of Current WCS and accessible via C-+ bindings. 

 

	 	4.1.3	A Selector for openSUSE 10.3 and SUSE Linux Enterprise Server 10 interoperating via ISIPvl.0 with the GetToken functionality of Current WCS. 

 

	 	4.1.4	A Selector available for Linux interoperating via ISIPv1.0 with the GetToken functionality of Current WCS and accessible via Java bindings. 

 

	 	4.1.5	 A Selector available for Linux interoperating via ISIPvl.0 with the GetToken functionality of Current WCS and accessible via C# bindings. 

 

	 	4.2	Interoperability. Either via a face-to-face meeting or an application-sharing collaboration meeting over the Internet, interoperability of the Selector
Deliverables will be shown using: 

  

	 	4.2.1	The Access Manager STS or the Higgins Project STS. 

  

	 	4.2.2	Access Manager. 

  
 [*** Confidential Treatment
Requested] 
 Page 5 of 6 

	 	4.2.3	Firefox. 

  

	 	4.2.4	Safari. 

  

	 	4.3	Card Import/Export. Either via a face-to-face meeting or collaboration over the Internet, compatibility of the Selector Deliverables will be shown for card
import/export. 

  

	 	4.3.1	Cards exported from WCS are successfully imported into the Novell Selector, and user access to resources with those cards using the Novell Selector is preserved.

  

	 	4.3.2	Cards exported from the Novell Selector are successfully imported into WCS, and user access to resources with those cards using WCS is preserved.

  
 [*** Confidential Treatment
Requested] 
 Page 6 of 6

Source: [{"source": "alea-institute/alea-institute/kl3m-data-edgar-agreements/train-00182-of-00352.parquet"}, [{"source": "alea-institute/alea-institute/kl3m-data-edgar-agreements/train-00182-of-00352.parquet"}]]