adding docker secret support to another project on GPL3 licence

[ynuyasha]

Hi, i have a question as describe here https://docs.docker.com/engine/swarm/secrets/#build-support-for-docker-secrets-into-your-images they suggest to use your approach to adding docker secret support into another project.
Now i have code it and i'm inspired to your code but the project where i need to put the code is on GPL3 licence.
So the maintainer of project can't include it because i can't add GPL2 only code licensed (your code) into a GPL3 project.
Can you help us to understand if we can include your code into a GPL3 project?
Here is the internal discussion ever-co/ever-traduora#202

[wglambert]

From my understanding this section here allows you to redistribute it under GPL v3

mysql/LICENSE

Lines 296 to 299 in a09a716

	This program is free software; you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation; either version 2 of the License, or
	(at your option) any later version.

From "The license notices" https://www.gnu.org/licenses/gpl-howto.html

[tianon]

If all you're looking for are the (trivial IMO) file_env bits, they're also available under other repositories with different licenses:

• https://github.com/docker-library/mongo/blob/7ae285a368d09a0362d0794076bf895afc782c2a/docker-entrypoint.sh#L34-L54 (Apache 2.0)

• https://github.com/docker-library/postgres/blob/376f87ce3b00273c5ea1f5446d6876227d5ddf07/docker-entrypoint.sh#L5-L25 (Expat/MIT)

• https://github.com/docker-library/rabbitmq/blob/e62f193dfcf9aee378e256cbbfae30363480c3a7/docker-entrypoint.sh#L4-L24 (Expat/MIT)

• https://github.com/docker-library/redmine/blob/c46672e13489aa7c77ee95fd697b99cdfd836cd8/docker-entrypoint.sh#L5-L25 (GPL 2.0)

[evereq]

@wglambert thanks for your help, but I don't think it's correct.

That part you found in the LICENSE is a standard suggestion about how to put GPL v2 license (described in the same file) into some program/library. It basically saying what authors can / should / may do etc.

The problem is that author may add ("at your option") text "or any later version" OR may decide NOT to add that text into license.

From what I see in the MySQL license (

mysql/LICENSE

Lines 296 to 299 in a09a716

	This program is free software; you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation; either version 2 of the License, or
	(at your option) any later version.

) it does not mention "or any later version" anywhere (except that description code which is again about how to add the license to the software, not how it's distributed under that license, etc).

So we can conclude that that specific code released under GPL v2 and NOT "or any later version". That means we can't include it into GPL v3 / AGPL v3 code etc.

Now, as @tianon found, the same code incorporated into lots of MIT licensed projects (e.g. Postgres, RabitMQ), it's hard to know who first write it. I.e. could be it was first introduced into Postgres and later copied into MySQL? If so, we can copy it from PostgreSQL MIT licensed file into other projects. If, however, it was first added to MySQL and later someone copies it to PostgreSQL / RabbitMQ libs, it's not strictly legal, etc.

So as always with software licenses, we need to know who first write that code and under what license to make any legally correct decision :))))

[tianon]

... as @tianon found ... it's hard to know who first write it.

I can give you a clue -- it's the same person who gave you all those links. 😄

[evereq]

@tianon that's great, is there any chance to change the license to be "GPL-2.0-or-later" for MySQL and others (only for those released under GPL-2.0-only of course) ? ;)

More info about that in https://www.gnu.org/licenses/identify-licenses-clearly.html

[tianon]

Sorry for the delay - we try to match the license of the upstream project we're packaging (it makes it easier to move patches back and forth between the upstream and the packaging, and is a common practice in Debian packaging too, for example). There are no current plans to try re-licensing here or elsewhere, sorry!