SQL Server container improvements regarding licensing

[lukaseder]

From how I understand SQL Server's docker container licensing, there are two things that need to be provided to the docker image:

• ACCEPT_EULA=Y
• MSSQL_PID=<your_product_id | edition_name> (default: Developer)

The current approach of having to place an image name in a static file is a bit clunky and doesn't cover the above sufficiently

1. I don't want to run SQL Server using a Developer edition license. I prefer the Express Edition. I guess I can use withEnv("MSSQL_PID", "Express") but it would be nice if I had an enum to choose from with API placed directly on MSSQLServerContainer
2. The Db2Container has an acceptLicense() method, which I think would be nicer than this file on the classpath. Especially, because I'd like to run integration tests using different images of SQL Server, but from the same Maven project, so I cannot easily reuse this file without a build preprocessing step that writes the image name into the file prior to starting the integration tests.

---

See:
https://hub.docker.com/_/microsoft-mssql-server#environment-variables

[KyleAure]

For your second comment I have a PR open to add an acceptLicense method to the SQL Server container here: #2085

Just need a review :D

[bsideup]

@KyleAure if only review :) There are some legal implications that we need to review to be very careful about not breaking any license or anything :)

The Db2Container has an acceptLicense() method

the Db2Container was contributed by IBM's employee who assured us that the method is fine from legal PoV.
I will try to find someone from Microsoft (cc @jdubois) to confirm whether it is okay for MSSQL or not 👍

[lukaseder]

the Db2Container was contributed by IBM's employee who assured us that the method is fine from legal PoV.

Hah, right. We entrepreneurs are all with one foot in prison...

[jdubois]

I'm not a lawyer, but on https://hub.docker.com/_/microsoft-mssql-server the license part looks pretty clear to me:

By passing the value "Y" to the environment variable "ACCEPT_EULA", you are expressing that you have a valid and existing license for the edition and version of SQL Server that you intend to use. You also agree that your use of SQL Server software running in a Docker container image will be governed by the terms of your SQL Server license.

I believe it's pretty clear that anybody using SQL Server needs a license, as it's not OSS, so this shouldn't come as a surprise to anybody.

[lukaseder]

I believe it's pretty clear that anybody using SQL Server needs a license, as it's not OSS, so this shouldn't come as a surprise to anybody.

By using OSS, people also agree to the relevant license, even without such a 'Y' character being sent anywhere.

[KyleAure]

If the decision that needs to be made is between having a resource file to accept the license vs. having a programmatic method to accept the license. Then I think we are in the clear either way.

We are acting as a proxy on behalf of the user to use a docker container in java. We are just passing their arguments to docker. We are not making any decisions on the behalf of the user. Therefore, a user calling the method acceptLicense() in their source code is equivalent to setting an environment variable, and just as traceable as having a resource file. (though I also am not a lawyer)

[torrespro]

I'm trying to add MSSQL Server to testcontainers spring-boot and noticed that the docs about the acceptLicense() in MSSQL Server: https://www.testcontainers.org/modules/databases/mssqlserver/ are a little bit ahead of the release ;-)
acceptLicense() is not included yet in 1.14.3, correct? I see the merge of @KyleAure PR has been done but it's for the incoming 1.15.X I believe...

[Illutax]

Cross referencing #2085
This is a duplicate, right?

[KyleAure]

Correct, I believe this issue can be closed

[E14]

I'm surprised nobody has cared yet, but it is an END-user-license that is being accepted, committing this acceptance in a repository (which I assume is the goal when loading it from the classpath) inherently causes this to be run by other users than the one who has "accepted" the license,

Should the container license acceptance not be looked up in the relevant user's directories?

• $XDG_CONFIG_HOME/<scope> on Linux
• %APPDATA%\<scope> on Windows

Maybe with classpath as fallback for backwards-compatibility, but showing a warning, if used.

[Illutax]

I'm surprised nobody has cared yet, but it is an END-user-license that is being accepted, committing this acceptance in a repository (which I assume is the goal when loading it from the classpath) inherently causes this to be run by other users than the one who has "accepted" the license,

Should the container license acceptance not be looked up in the relevant user's directories?

• $XDG_CONFIG_HOME/<scope> on Linux
• %APPDATA%\<scope> on Windows

Maybe with classpath as fallback for backwards-compatibility, but showing a warning, if used.

In the case where the SQL Server is ran in a test suite, like here in the case of Testcontainers, the consent is given explicitly by the person who implemented it and implicitly by every person running it.

[E14]

I think Microsoft's lawyers would object vehemently (otherwise, what's the use of implementing the ACCEPT_EULA environment variable in the first place), but regardless ...

My point is about enabling developers to make it an actual end-user acceptable license instead of whomever-commits-the-file-license. By adding additional sources, bound to the user, you can't make it worse.