XNA EULA - Network Impact

Dec 21, 2007 at 6:07 AM
An interesting thread on the XNA boards just came up about the XNA EULA. If you really read it (and who does? Come on, be honest.) , there's an interesting passage in 2.d:

    2. Additional Licensing Requirement and/or Use Rights.
        d.  Communication Features.  Any voice-chat features implemented in any programs created with the software must utilize the voice-chat channel provided in the software.  You may not implement any text chat functionality in any programs. 

From what I can tell, this is applicable to all programs using the XNA assemblies in any way. And to me, this implies that even if we implement our own networking solution, we cannot implement text chat or voice chat? Someone please tell me I'm mis-reading the EULA. Please.
Dec 21, 2007 at 6:54 AM
Sadly you are reading it right. Though I do think this is minded towards Xbox programs, it sadly also affects windows users. I didn't read the EULA, shame on me, but if this is in the general section then it holds true on all platforms.
Dec 21, 2007 at 1:19 PM
Boy thats bad. I hadnt realised that, and I was going to add text chat add some stage. I seriuosly hope it only applies to Live.
Dec 21, 2007 at 3:01 PM
If true, it essentially kills System.Net support. Sure, you can just not have in-game communication, but what modern game doesn't support some form of communication? It would make any team-based game nearly impossible. The best you could do would be have an AI entity give orders to players or something like that.

That's really lame! It really does cripple XNA as a games platform.
Dec 21, 2007 at 4:27 PM
What would happen if we say, ignored this and did it anyway?

Hypothetically of course :)
Dec 21, 2007 at 5:04 PM
  1. Technically, Microsoft could sue for breach of EULA.
  2. Any potential serious users of the engine will see the breach and immediately discard it as an option for their game/technology, for risk of themselves being sued.
  3. No QuickStart code could ever be used for commercial purposes.
Dec 21, 2007 at 5:08 PM
The hypothetically wrorst case is MS dropping the legal department over the project, everyone involved would be have a legal case, and in case you lost it (Which would be most likely) you could be fined in the 100 thousands of $. The amount would depend on how much value MS would deem it would loose by having a project breaking the trusted image they have regarding Live and the trustfulness it provides.

Would MS even be conserned about a little project like this, well I think that would depend on the success. But that's just my personal oppinion, but I do not think that we should risk it.
Dec 21, 2007 at 5:12 PM
The legal waters in the software industry have been getting very murky over the last 5 years or so. Especially here in the U.S., there have been a significant number of academic research papers that have attached patents. This means that if you read one of these papers and implement it's techniques/ideas/research data or implement a similar algorithm, you can be sued for patent infringement by the author(s), if you did not obtain prior permission of the author(s). This even applies to open source software. Before reading any research paper or other article on a technical topic, always make sure there are no attached patents. Otherwise, you could really screw yourself over just by reading it. If it relates to your own written code in any way (past or future), you could get in trouble.

Of course, if you have no commercial interests, then you're fine. No one's going to come after a non-profit hobbyist. But if your code is on the internet and could potentially be used by commercial software (even open source), then you need to really be careful.

Personally, I find it all BS. You should not be able to do such things, but I'm not the one making the rules.
Dec 21, 2007 at 5:21 PM
I just saw that I forgot to post the XNA boards link: http://forums.xna.com/thread/38387.aspx
Dec 21, 2007 at 5:27 PM
I was only asking, as I suspected the answer would involve lawyers :)

Seriously we need this clarified by someone official, just to be safe.
Dec 21, 2007 at 5:32 PM
That's what the XNA boards thread is about. Just waiting on a semi-official answer. Obviously the XNA guys cannot give an "official" legal answer, but they should be able to explain the intent of that clause.
Coordinator
Dec 21, 2007 at 9:38 PM
If XNA 2.0 means we cannot have any chat, even without Live, then I'd rather downgrade to 1.1 and just use Sockets. Seriously this is idiotic.

What if we use Sockets and make sure chat is unencrypted?
Dec 21, 2007 at 9:45 PM
I'm still waiting on an answer on the XNA boards. The EULA says nothing about this only applying to Live, but I want to hear one of the XNA guys confirm.

I was thinking the same thing about going back to 1.0 refresh. I can live without VS Pro integration, since I can still develop all of the library code in VS Pro and just use Express for the test apps. What else does 2.0 really give us? Freaky render target behavior and the inability to opt-out of render targets being automatically cleared when bound to the device? The new clear behavior has been getting to me lately.
Coordinator
Dec 22, 2007 at 2:25 AM
Edited Dec 22, 2007 at 2:25 AM
The VS pro integration is not something that has affected me yet anyhow, so I wouldn't be bothered by it. Granted, I'd rather use pro, but I'd much rather including chatting in the engine. We'd also lose Windows Live functionality, but that is starting to be much less appealing than it originally seemed, especially without the XBox Live functionality we were already thinking of losing (or caring less about).
Dec 22, 2007 at 12:15 PM
I wouldn't scrap 2.0 just yet. I mean we aren't even ready to implement any kind of communication before we add support for more players, which isn't actually before 0.21 which has a release around May. A lot can happen before that. There might be a new release of Xna with a different EULA, now that the issue has been brought up. Maybe different EULAs will be introduced targeting Xbox/Live and Windows.

Don't forget that the EULA also states that you can only use it on Xbox/Windows which makes Mono.Xna impossile to do.
Dec 22, 2007 at 1:05 PM
I agree with Sturm. I think its very unwise to base our engine on an outdated version. In a commercial scenario would you make a new game using DirectX 8?
Dec 22, 2007 at 3:50 PM

mikelid109 wrote:
In a commercial scenario would you make a new game using DirectX 8?


If the DirectX 9/10 EULA's were too restrictive, then yes. Then again, I'd just use OpenGL anyway ;)


Sturm wrote:
Don't forget that the EULA also states that you can only use it on Xbox/Windows which makes Mono.Xna impossile to do.


Not necessarily. Mono.Xna is a different implementation, not Microsoft's code. It just has the same API interface.


Sturm wrote:
There might be a new release of Xna with a different EULA, now that the issue has been brought up. Maybe different EULAs will be introduced targeting Xbox/Live and Windows.


The issue I have with that is the word "might." It's pure speculation that this will change. We can't base our design around assumptions, at least not until one of the XNA guys says its something they want to change for the next version.
Coordinator
Dec 22, 2007 at 4:21 PM
I'm not saying scrap 2.0 right now, but we should ask ourselves what the benefits of 2.0 even are. Things I can see are

  • Support for different game input devices (relatively important)
  • Support for live (doesn't seem as important as I once thought)
  • Some minor bug fixes
  • VS Pro integration

I can't think of much. I agree it would suck making it for an old version, so we should think about it, it just seems like the new version is a step back in some ways.
Dec 22, 2007 at 4:39 PM
Those are API changes, but what about the library changes? Whose to say that the dll's themselves arent more efficient? Or faster? Or less buggy? But I agree with you, it hasnt brought much to the table. What was the support for different game devices, I missed that announcement?

I just think its foolish to work with an outdated version, but the EULA may force us to. I say play by ear until we hear officially from the XNA Devs.
Coordinator
Dec 22, 2007 at 5:23 PM
Not sure the XNA Devs will legally be able to give us an answer, but so far it sounds like we couldn't even do our own un-encrypted chat system. XNA 2.0 supports other types of input devices than the stock 360 controller, such as a guitar, the chatpad, a joystick, and some others.

As far as efficiency, the only things I specifically remember are that the 360 SpriteBatch method no longer creates garbage (or something like that), and the timing of the update() and draw() methods was fixed so that draw() would only be called once for every update().
Dec 22, 2007 at 5:39 PM
This is what Shawn Hargreaves posted:

The text chat limitation stems from laws around encrypted network communications and export of encryption technology between different countries. Live network traffic is encrypted, so if you used this to send text communications, you'd come under all sorts of funky laws (USA has the Patriot Act, other countries have similar legislation). Regardless of what you might personally think of these laws, Microsoft obviously has no choice but to obey them!

In some future version we'd like to add something along the lines of a SendDataOptions.Unencrypted flag, which could be used to legally send text chat data, but we didn't have time to get that in this first release.

That makes itsound like it only applies using Live, whihc isnt so bad, but thats only my interpretation. Im intregiud about the guitar, Ill look into it. I knew of the chatpad, as you change the player index on the method to access it.
Dec 22, 2007 at 6:29 PM


mikelid109 wrote:
This is what Shawn Hargreaves posted:

The text chat limitation stems from laws around encrypted network communications and export of encryption technology between different countries. Live network traffic is encrypted, so if you used this to send text communications, you'd come under all sorts of funky laws (USA has the Patriot Act, other countries have similar legislation). Regardless of what you might personally think of these laws, Microsoft obviously has no choice but to obey them!

In some future version we'd like to add something along the lines of a SendDataOptions.Unencrypted flag, which could be used to legally send text chat data, but we didn't have time to get that in this first release.

That makes itsound like it only applies using Live, whihc isnt so bad, but thats only my interpretation. Im intregiud about the guitar, Ill look into it. I knew of the chatpad, as you change the player index on the method to access it.


That's just Shawn's justification for why the restriction applies to Live. Read the EULA, specifically 2.d. No where do I see anything that limits it to Live-only. It's a blanket clause.
Dec 22, 2007 at 7:44 PM
Overall, I have mixed feelings about XNA Game Studio 2.0. It took a step forward with VS Pro integration and a few bug fixes. But it also took a step backwards with how much it does for you behind the scenes. By that, I mean it does too much for you. Looking at PIX logs, there are quite a few extra calls to the device that are just there for checking. For instance, for most of the draw calls, an IDirect3DDevice9::GetDepthStencilSurface call is made to verify that the depth buffer is compatible with the back buffer in size and MSAA settings. I'd much rather have a driver error than suffer the overhead of constantly retrieving the damned depth stencil surface for everything I do.

Live in XNA is a play toy. You can't do anything serious with it. And apparently all networking is severly limited in 2.0 now by the EULA. I won't say I'm disappointed, because the XNA team really did a great job with what they've done so far. But after seeing the release of 2.0, I have to say I don't think XNA is ready for serious game development yet.
Dec 22, 2007 at 11:56 PM
Edited Dec 23, 2007 at 12:07 AM
I share your feelings about XNA's current course of development, shaw. It feels odd.
So I had a short discussion with some other guys over at a German board.
Someone in the board suggested to use external APIs or XNA Refresh to code messaging features but stay on
2.0 for all the other stuff.
And at first I thought this to be a good idea.
But then I realized it may be not.
So let me explain, what I think... at least at the moment without further clarification by MS.

  • Any voice-chat features implemented in any programs created with the software must utilize the voice-chat channel provided in the software.
  • You may not implement any text chat functionality in any programs.

The first sentence explicitly mentions XNA Studio 2.0 (called software). It can be read as follows:
As soon as version 2.0 is involved in the creation of a program you must not program voice chat features that don't use 2.0.

I came to this conclusion because I think the first underlined part relates to 'any programs' and not to
'Any voice-chat features'.
It completely negates the usage of third party APIs or Refresh for coding voice chat features as long as
the programer uses 2.0 for the creation of a program (game client or whatever) as a whole. Even if the resulting program was only partly based on 2.0.

The second sentence 'worsifies' the situation.
It doesn't even mention XNA 2.0 (software) anymore.
That line just plainly forbids text chat features in the resulting program at all when you use XNA 2.0 to
create that program. Not even a slightest possibility for an interpretation as the whole EULA is related
to using 2.0.

So while the first sentence leaves some space for interpretations of the kind whether 'created' relates to 'any programs' or
just 'Any voice-chat features' (which would leave us the option to slip through and use a third party API) the second sentence does not.

-------------------

But despite this odd situation I'd like to express my wish to continue on the project at least until
there are some words from the officials.
And I eagerly hope they do clarify things in a positive way. The XNA-community rocks. I learned so much
in so little time - would be a shame to see it go to waste because of some fuzzy laws.
Dec 23, 2007 at 1:41 AM
Yeah, that's the crux of the problem. That clause does not mention "Live," so is extended to all programs that use XNA Game Studio 2.0 in any way (reference the assemblies, use the content pipeline, anything).

To an extent, I think people are misled a little bit by XNA Game Studio. You see people ask questions like, "why isn't XNA Game Studio used in professional, commercial games?" and the typical response is "it just takes time for adoption." The cold, hard truth is: XNA isn't ready for "prime time" yet, and the EULA makes that painfully clear. Completely forget about Xbox for the moment because you are expressely forbidden from commercial Xbox endeavors without prior permission of Microsoft. Windows is supposed to be free reign, but you end up with funky EULA clauses like this one. And another gem (sarcasm, yes) I found this evening:

3. [...] you may not:
    * work around any technical limitations in the software;

What does this mean? If XNA's implementation of SpriteBatch has a bug, I can't write my own, fixed version? XNA doesn't support Direct3D 10, so if I created a wrapper, I couldn't use it and XNA in the same project to provide users with a choice of renderers? If I wanted to use FMOD instead of XACT to get access to audio buffers, I couldn't?

This one confuses me even more than the network clause!
Jan 2, 2008 at 3:33 PM
Edited Jan 2, 2008 at 3:35 PM
I found this on the forums:


Do keep in mind that the networking component does not get installed as part of the XNA redist. For a user to run a networked XNA game they would have to install XNA Game Studio. LIVE support is currently a developer only thing, much like the Xbox 360 platform is. So for your users to run your game, they'd have to not only make sure they install the .NET 2.0 redist and DirectX 9.0c redist, but they'd also have to install VC# Express 2005 and XNA Game Studio 2.0. It's quite a lengthy process, so keep that in mind as you are working.


That basically rules out Live for me. I didnt realise you needed VC to even run it. Im putting Live networking on the back burner for now then, and will concentrate on Sockets, as this seems the only real possibility.
Jan 2, 2008 at 5:05 PM
Yeah, that was always part of the problem. They keep promising this wonderful "YouTube of games" (though I disagree on the feasibility of such a system), but I just can't bring myself to write software against such a system that doesn't even exist yet! If they provided some information on it, then it'd be different. But all they're doing right now is telling people to "write XNA games and use LIVE networking" because "once the distribution problem is fixed, you'll have this wonderful system." As far as I'm concerned, it's all dreaming and marketing, at least until I see some actual facts on it.

Supposedly some details are coming during the GDC in February. We'll see...
Jan 2, 2008 at 5:54 PM
Also, dont forget they failed on promises before. They promised us a professional version of xna, and never delivered. Im pleased not to have to pay extra, but this means the focus is still on 'for fun' from the xna devs point of view. Basically, at the minute XNA is stuck as a plaything in my view, its hard to do anything serious with it.
Jan 2, 2008 at 6:19 PM
Edited Jan 2, 2008 at 6:19 PM
The following is just my speculation and may or may not be based in fact:

Based on the comments I've been seeing over the last 6 months or so from Shawn and the rest on the XNA team, I'm starting to get the feeling that they bit off more than they could chew with the whole XNA Game Studio concept. For years, there have been fringe groups arguing that C# should be brought up on par with C++ in the games industry, and the big road block there was tools and support. Managed DirectX 1.1 was missing a lot, and Managed DirectX 2.0 was never officially released from beta. Short of writing your own wrapper, or P/Invoking into OpenGL, you really didn't have a good way to write graphics code. Not to mention the redist mess with the Managed DirectX versions.

Now, here comes the concept of XNA Game Studio, a fully-managed solution that not only allows C++ -level access to DirectX in C#, but is fully supported on the Xbox hardware. Hobbyists would be happy, because they could use C# and not have to learn C++. Indies would be happy with a level of "official" support through the XNA Game Studio tools. Commercial/professional developers would be happy with much-improved game turn-around times through greater productivity in a "better language." That sounds all well and good, but if you really think of the technical hurdles, there's an insane amount of work to actually do something like this. The Compact Framework team ported their code to the Xenon (PowerPC) architecture, but their time is very limited on the project and can provide a barebones implementation at best. Hardware floating-point support was the only "new" feature they could add to their code. The XNA Game Studio team was left with wrapping the "important" parts of DirectX on both Windows and Xbox. But herein lies a problem: the Xbox dev team will never allow Xbox programs that allow user-code to execute. The security ramifications are just too great. So, the XNA Game Studio team must create a "user mode" within the CLR that is effectively a sandbox and verify that it is secure. So, not only does an Xbox CLR need to be created, the DirectX libraries on Windows and Xbox need to be wrapped, and some way of making it all work in .NET be produced, but the XNA team basically needs to write a quasi-OS for the Xbox. The amount of effort required is staggering!

But, if they could succeed in this, they can successfully create a generation of professional C# game programmers. This would equal more Windows/Xbox exclusive titles, that are even harder to port to Linux, MacOS, PS3, etc.

Okay, so that last bit is mainly conspiracy theory, but it does make you think.
Jan 2, 2008 at 6:21 PM
Xna is mostly a first release indie framework, so I'm not having any painpoints at this time. Moving forward I really hope that the EULA, networking and a few other issues are going to be resolved. I'm not expecting this to happen within the next year, but then again I'm not expecting to release any final product within that timeframe anyway.

Currently the most annoying issue at this time is the EULA, which I really hope will be solved within the next months.
Jan 2, 2008 at 6:23 PM
No offence, but I hope your wrong. If they bit off more than they could chew, they may decide one day to un-bite, and kill off xna. I suppose this is what happened with managed DX, and I sincerely hope that it doesnt repeat for XNA.
Jan 2, 2008 at 6:45 PM
XNA is already much more supported and has a huge marketing campaign compared to Managed DirectX. I'm not so concerned with XNA Game Studio being discontinued as I am it making all of these claims about future functionality and then not delivering.

I perfectly understand their limited resources, I just think XNA is having a major identity crisis. It's being advertised as a full development solution for game development, including commercial development, but it's lacking important features and distribution channels. Not a week goes by when there's not a "why isn't XNA used in commercial games" thread on the XNA forums, and the typical response is "it just takes time for game studios to adopt." While that may be true, I'd be willing to bet few studios have even considered XNA Game Studio due to its restrictions, both technical and legal. If you're looking at technology for your next game, you're probably not going to consider a product that "may" be viable in the future.
Jan 4, 2008 at 2:06 AM
Well, despite what the EULA seems to imply, Shawn has posted the official lawyer response and it's great news! The restrictions only apply to LIVE networking: Xbox LIVE and Games for Windows LIVE. We are free to do whatever we please with our own networking solution, provided we follow local laws. Obviously text encryption is a gray area, but we just won't encrypt it!


Shawn Hargreaves said:

Official statement from our lawyers:

To clarify the intention of Section 2.d. of the 2.0 EULA:  this restriction only applies if your program is interacting with Microsoft’s networking services, e.g. Xbox or Games for Windows LIVE service (“LIVE”).  If you are implementing a solution that does not in any way interact with LIVE then this section would not apply.  We are evaluating an unencrypted means to implement text chat in the next GSE release so that you would be able to implement text chat functionality over LIVE. 
Please note that if you do decide to implement any non-LIVE networking functionality with communication capabilities, you are responsible for comply with any applicable legal and regulatory requirements. 

Jan 4, 2008 at 5:29 AM
Really great news indeed. That's one issue less to worry about.
Jan 4, 2008 at 9:09 AM
Awesome! I guess we can stay with GS2.0 now, with no real worries.
Coordinator
Jan 4, 2008 at 3:38 PM
So the question now is, do we even have the choice of supporting Live, even if the non-Live networking supports chat? The lawyer's response in Shawn's post makes it sound like we could have our non-Live support text chat, and we could still support Live as long as the text chat is not enabled.
Jan 4, 2008 at 3:51 PM
That does seem to be a gray area. I would just say ignore LIVE for now, since we can't distribute games using it anyway.
Jan 4, 2008 at 5:30 PM
I fully support not using Live for the next couple of releases.
Coordinator
Jan 5, 2008 at 6:41 AM
Releases of this engine, or XNA? :oP
Jan 5, 2008 at 6:28 PM
I was a little worried when the product lineup for the next generation Visual Studio Express Editions omitted the XNA Game Studio version anything, but instead focused towards Visual C++ 2008 Express and Game Creators GDK. Granted, I'm sure that deadlines and other matters made them choose between XNA and not displaying it, but to show something else entirely? Just struck me as odd.

And I do apologize if this has been discussed already, I found this forum by accident.

And who's to say that XNA won't be used professionally? Professional Game Studios might have more options with XNA than Microsoft releases publicly that might by chance allow them to release an XNA-based game on the XBox 360. It's all more a matter of control: to ensure that the XBox 360 remains secure, they have a certain level of checks and balances, one such check could possibly be to ensure that unverified code will never run (by never letting it get to market). Wouldn't surprise me any if even professionals have to go through Microsoft to get an OK on their game, XNA or no.
Jan 5, 2008 at 6:51 PM
I believe the omission on the Visual Studio page is because XNA Game Studio does not support Visual Studio 2008.

XNA Game Studio could be used professionally, and there is one XBLA game, Schizoid, planned for release this year. And yes, they had access to tools beyond what XNA Game Studio provides on Xbox, like the Xbox version of PIX.

You're also right that the Xbox does not allow unverified (aka "unsigned") code. All Xbox executables are encrypted and hashed. The hashes are signed by a private key (known only to Microsoft) and stored in the executable. At run-time, the Xbox hypervisor (security layer) will decrypt the hash, and verify the executable is unchanged since the original signing. No Xbox game/demo/downloadable-content is released without first being certified and signed by Microsoft. That's true for professional developers.

The problem is XNA adds another layer of complexity to this. The code we write is unsigned and unchecked by Microsoft. To get around this, the XNA run-time sets up a user mode on the Xbox processor that acts as a sandbox to create an isolated address space. Only managed code is allowed. The problem here is two-fold. First, you're stuck with the code that the Xbox CLR can generate for you, and from experience I can tell you it does not do a good job. The Desktop CLR is much better, let alone what a good C++ compiler can do for you. Second, everytime the XNA Framework needs to call into the Xbox OS or hardware, it needs to go through system calls, which require a user mode to kernel mode switch and cause additional overheads. The framework internally tries to batch as much as possible to minimize the number of system calls, but its still overhead that does not exist (or at least not at the same level) in the native world.