Feedback Plastic SCM EULA concerns -- possibly resolved by Unity acquisition?

I have just begun evaluating Plastic SCM for my organization, and was setting it up for one of my personal projects as a low-risk way to learn about the tools without disrupting commercial work. During installation of the desktop client software (cloud version), I took the time to read the EULA, and I have some significant concerns that I hope will be addressed by Unity now that Plastic SCM has been acquired by Unity Technologies.

Please understand that I don't mean to be unduly paranoid or negative -- I really like what I have seen so far of Plastic SCM, and I want to be able to evaluate it and hopefully to recommend adopting it for our team. Furthermore, everything I have read on the Plastic SCM documentation site, and things I have read in user forums here on the Unity web site, lead me to believe that Codice has nothing but good intent to do right by their customers. But lawyers and courts are notorious for enforcing contract wording as written, not as intended, and this prompts me to ask these questions of the Unity team, who are presumably now in charge of legal matters related to Plastic SCM.

I apologize for posting this in the Collaborate forum section -- there does not yet seem to be a section dedicated to Plastic SCM.

This is a quote from the EULA for Plastic SCM:

16. Use of Customer Name
Customer agrees that the LICENSOR and its authorized Partners may use Customer's name and logo in advertisements, other promotional material and the LICENSOR'S website.​

I am currently setting up one of my personal projects in Plastic SCM to try it out, but before I even consider putting company projects on their software, this is something that needs to be discussed with my CEO.

From my own perspective as a developer, I have multiple concerns here:

1. Of all the software I have ever licensed, I cannot recall even a single ISV that expected to be able to use my company's name and logo on their web site to promote their product. If a company for which we are a customer wants our endorsement and use of our logo, they are obligated to politely ask us for that. Imagine if every piece of commercial software your company used allowed the seller to use your logo and name on their web site.
2. Pursuant to the preceding point, this clause could land employees of some companies in a lot of trouble if they don't notice that clause or don't realize its significance. Imagine, for example:
   • You work for a defense contractor or financial company or similar employer with strict confidentiality requirements. You download a piece of software for technical evaluation, intending that if you want to use it permanently, you'll be going through your organization's normal procurement process. Knowing you don't have legal contract-making authority for your organization, you skim through the EULA and agree to it.
   • Having that agreement in place, Codice (acting in good faith) decides that your organization would be a wonderful addition to their marketing material. They post the company's name and logo. Is there anything in section 16 preventing Codice from referring to an organization in their marketing that has not even committed to a paid license or subscription yet?
   • If someone in Legal or management at your organization notices that logo, they may initiate legal action against Codice only to find out that one of their own employees unwittingly authorized the use of the logo. It's an embarrassment to the customer and to Codice and possibly results in disciplinary action against you, the employee.
3. The clause also specifies "authorized Partners", which sounds pretty open-ended to my non-lawyer reading of the sentence. The customer presumably has no control over who LICENSOR chooses as an "authorized Partner" in the future. An "authorized Partner" to LICENSOR could, coincidentally, be a direct competitor of the customer -- and now the customer has allowed a direct competitor to use their logo for marketing purposes.

Aside from this clause in the EULA, there is something else that I could not find in the EULA. As stated above, I am not a lawyer, so I am open to being corrected, but I found nothing at all that prevents LICENSOR (Codice) from disclosing, publishing, selling, or using internally the source code customers store in their cloud.

• There are clauses related to privacy of personal information, but I could find nothing about project data or source code. This may be more important to some customers than to others, but for many of my company's clients, we are under Non-Disclosure Agreements (NDAs) which require that we protect their project data and code against unauthorized disclosure. It concerns me that our technical and creative team could decide Plastic SCM is the tool we want to recommend, but the CEO or our company's legal counsel could determine that we aren't allowed to use it simply because there is no protection for project data in the EULA.
• Another clause in the EULA's liability limitation section seems to excuse LICENSOR from any significant liability (beyond a refund of fees) even if our data is compromised or lost due to their "negligence" (the word is used in the clause to which I refer).
• Examining the EULAs for other organizations (including Unity Technologies) with whom our team interacts in similar contexts, there is typically some level of protection in the EULA in which the cloud service provider disclaims any right to the customer's copyrights, trademarks, or proprietary data just because it is stored in their cloud servers.

In conclusion, I reiterate that my personal belief is that there is no ill intent in the EULA, that these are simply matters that were not brought up for discussion because most users who install the software are technical or creative and have other priorities than deeply scanning the EULA. It is my sincere hope that someone from Unity Technologies can put my concerns to rest, and we can all get back to creating interesting things in Unity.

 

I agree with you. It's can also have Codice lose potential customers when the CEO refuses the employees request to use Plastic for that reason. Let's keep in mind that some developers have to deal with hierarchies who think saving the project on a USB drive is good enough.

On the other end, I don't see Codice using my company name without asking first, no matter what the contract. Let's say that I release a game successful enough to be a household name. Codice proudly mentions it on they website only to be publicly contradicted by me saying we used the competitor's product on that project. That wouldn't look very good for them.

 

Update: I shared this information with our CEO last week at our team meeting, and her response was exactly what I expected: Nope.

 

Predictable.

I think you should post this on Plastic SCM forum or on their forum or by Email. You'll be in contact with someone from their team. I don't think they are active on Unity's forum.

 

About source code protection, if you work with clients which demand confidentiality, storing source in the cloud is a big no-no anyway.

 

The data is encrypted if you need and you can self host on site.

 

Agreed, and that varies from one client to another for us. The concept we have in mind is to use Plastic's cloud for non-confidential situations, or when our contract with our customers allows us to use their encrypted storage, and to use an internal Git server and for the high-confidentiality projects (but with Plastic's UI as the front end).

For most of our clients, the fact that we can encrypt the data in the cloud would be sufficient -- but the broad rights to use our name and logo without further permission are a separate issue, and not dependent on where the data resides.

I'll reach out to the Codice support process with an inquiry; I started here because since Unity Technologies has acquired Codice, my assumption (as a non-lawyer) is that Unity now is the authoritative source for license/contract issues.

 

Any reasons you don't use Plastic directly for that?

 

For the high-confidentiality projects, we are contractually required to have all data hosted in our data center. We already have a well-provisioned Git environment with some automated build and packaging infrastructure, so there's an incentive to keep any on-premises Unity repositories as part of that environment.

Was your question directed toward the on-premises version of Plastic SCM server?

 

Yes, because it seems more convenient than setting up Git and then configure Plastic to use it. So I'm curious about your pros and cons on both solutions.

 

(EDIT: After I posted this, it looked a lot like a "wall of text", so I'm going back to boldface key points. This is just to allow easier skimming for those who don't want to read the whole thing; it's not intended as shouting.)

That's a fair question, and my answer starts by mentioning that we haven't made a definite decision yet, so we may end up doing the on-premises Plastic config. That said, there are several considerations for us, some of which are not likely to apply to other teams making a similar decision:

• Unity (and related tools) are only part of our engineering environment. We also develop and support open source applications on Linux and UNIX systems, and we have a team who offer services and software development for mainframe systems (including Linux on the mainframe). We've invested a lot of resources in Git tooling (our production build environments are heavily automated, and in the open source arena our automation directly interacts with corresponding systems at other organizations). If we use Git as our on-premises SCM for Unity, we can leverage all of that tooling -- and the deep Git expertise of most of our engineers.
• Counterpoint to the preceding: If we used Plastic's on-premise server, I could probably still make most of those tools work, although that's back to the same (valid) point you make about convenience -- the inconvenience is just at a different functional partitioning boundary.
• Although we have large (Fortune 100 and 500) customers, as an organization we are very small. Everyone wears many hats (as I'm sure those who work at indie studios can relate!). If we build an on-premises Plastic server, it falls to me as the primary maintainer. If we use Plastic's cloud, and for on-premises use the existing Git infrastructure, once I get that initially integrated, I'm "one of the people" who administers the server, rather than a single point of failure. It's better for my stress levels, better for the company's continuity if I'm off sick or on vacation.
• We're not a game company. Although we're perfectly able to offer Unity-ecosystem services to game companies, our own use of Unity is for visualization and simulation in connection with our other business areas (I didn't mention above, but we also create physical and logical designs for network operation centers [NOCs]). The implication of this is that our internal work (as distinct from contracts from customers from the Unity ecosystem) benefits from using the same tool set as other teams, because this facilitates collaboration.
• Finally, from an IT infrastructure standpoint, we're at a significant inflection point with respect to our on-premises SAN. Under my tenure as IT Manager, we rebuilt our SAN from scratch, with state-of-the-art equipment that has served us very well -- and obliterated the performance bottlenecks in our build systems -- but which is high-end gear at a high-end price. We're okay on space right now, but if we grow much larger we'll need to add more flash storage to the array, and that's a significant capital cost. That's the main driver for putting our non-sensitive Unity content into the cloud rather than on-premises. We can buy a lot of cloud storage for the price of upgrading our SAN, and in the Unity space we don't need the ultra-fast (parallel 10 GbE paths) speed that is needed by our developers. Unity projects tend to be huge, as you know, but a decent broadband connection to the SCM is sufficient for most Unity work I've done so far (including one customer project that was 75 GB). This relates back to your question because we anticipate being able to do most of our projects using Plastic's cloud, and dodge the local storage requirement and local sysadmin tasks entirely. For us, the on-premises SCM will be more of an annex to the main repository in the cloud -- and that drives a desire to minimize the amount of time we spend maintaining it, hence the strong desire to leverage the existing Git infrastructure.

This is pretty off-topic for my thread, so I have no one to blame but myself for the thread-drift, but I think you asked a very pertinent question. To be honest, answering your question in such detail, in writing, has helped to crystallize my own thinking on the decision. We are definitely open to both alternatives -- in the above points, I mostly painted the Git-favorable picture because I was answering your question of why we might want to go that route. But in my own mind (for all intents, this is my sole decision, because the rest of the team doesn't care as long as it works) this is still very much an open question. We are still very early in the evaluation process, so among other things the direction could change as we learn more about Plastic SCM and begin to test its Git integration features.

Thanks for sparking an interesting line of thought and forcing me to capture things more precisely than I had.