Our team is attempting to define guardrails on certain license types. We’d like to take the stance of “internally” vs. “externally” facing applications for a guardrail. For example: Internally Facing applications can use these license threat groups vs. Externally Facing can only use these.
Once we start down that path we run into semantics of these definitions.
Has anyone else defined internally and externally facing applications successfully for their developers?
Is there another guardrail that others have had more success with?
The definition or guidelines for identifying Internal vs. external applications usually requires input from your legal team. I am assuming you are worried about CopyLeft licenses. Ultimately your legal team needs to define it in terms they are comfortable defending. Once you have a good feel for what they are comfortable with, you can use Application Categories to define the external and internal applications if you want to have different security policies for these. Hope this helps.
I completely agree our legal team needs to define and this is primarily for Copyleft.
Our legal department was asking how others were defining. I think they’re looking to check their work and make sure they didn’t miss a use case. Due to our regulated industry, they have gone a bit more wholistic in their definitions that have led to several challenges from developers.
I wish I could give you a solid binary answer. We see various answers, often related to their business type. It is a tough question that depends on your business, risk awareness, and legal teams.
Can you discuss generically why this is causing issues for Dev teams?
So I am going to preface this with I am not a lawyer, but in general I would define internal applications as applications that are not distributed, run on private infrastructure, and do not directly expose endpoints or services to the public.
A good example of an internal application would be a data pipeline. Something that ingests data for your company, manipulates it, and then makes it available for other applications to utilize. Its endpoints or data exchanges are not publicly accessible. Or, maybe you have a log aggregator or some other logging tool that just aggregates logs from many different applications into a central location. That would also be an internal application.
Another example, you could have a pipeline that trains a new machine learning or deep learning model. That would be an internal application even if its output would be consume or utilized by an external application.
One caveat with internal applications is that there are licenses with obligations around not just code but data (e.g. certain CC-BY-SA licenses). Just because an application is “internal” does not give it carte blanche to use any license. I would still avoid Banned licenses.
External applications are applications that expose data, end points, services, or are distributed outside your company. Essentially there is a way for the public, client, user, or customer to interact with something your company provides.
A good example could be a set of services your company provides, or a web application. The web application not only exposes end points for data and services but also transmits code in the form of JavaScript to the client’s browser.