projectatomic / ContainerApplicationGenericLabels

Default Containerized Application Labels used to document the application and/or image
68 stars 29 forks source link

Proposal: Add a License Label #71

Open DanielFroehlich opened 8 years ago

DanielFroehlich commented 8 years ago

I would like to propose a License label that contains license information about the image. It will carry string containing license information. Could be simply the name of the license (GPLv2.1), or a comma separated list of several different licenses (GPLv2.1, Apache-2.0). License Names should be the short name from the osi.

All images should contain a License Label to easy use of containers for compliance and governance sensitive organizations.

TomasTomecek commented 8 years ago

Images are usually composed of software coming from multiple upstreams available under different licenses. Therefore I don't think that you can make an image available under a single license. Example:

$ docker run -ti fedora:24 bash
[root@e746d3568f80 /]# ls -1 /usr/share/licenses/ | wc -l
109

That's 109 different license texts.

How would this get solved?

DanielFroehlich commented 8 years ago

Maybe with a list of 109 entries in the label? The issue today is that license information can be located anywhere in the image and it is very hard to find it out. In the JBoss Middleware Domain, it would be e.g. /opt/eap/LICENSE.txt.

I think it should be the responsibility of the image provider to add license information to the meta data of the container.

On Mon, Jun 27, 2016 at 3:30 PM, Tomas Tomecek notifications@github.com wrote:

Images are usually composed of software coming from multiple upstreams available under different licenses. Therefore I don't think that you can make an image available under a single license. Example:

$ docker run -ti fedora:24 bash [root@e746d3568f80 /]# ls -1 /usr/share/licenses/ | wc -l 109

That's 109 different license texts.

How would this get solved?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/projectatomic/ContainerApplicationGenericLabels/issues/71#issuecomment-228745534, or mute the thread https://github.com/notifications/unsubscribe/ARrIW-OgpDLjVhvNero26uT6xU151Nsxks5qP9BugaJpZM4I-7-I .

Daniel Fröhlich Solution Architect Middleware OpenGroup Certified Master IT Architect

Mobile: +49 176 10 24 84 33 Phone: +49 711 96 43 71 44 E-Mail: daniel.froehlich@redhat.com

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander

TomasTomecek commented 8 years ago

The label could contain path to the license text; or it could be named ApplicationLicense to indicate that the field doesn't license every bit of the image.

DanielFroehlich commented 8 years ago

If I would work for an organization doing tough compliance checks on containers, it would be important for me that if the license label provides accurate and complete information, so that i can rely on it. If "ApplicationLicense" only covers parts, it does not help me.

I like your approach to point to the license file. So how about a Label "LicenseFiles", which contains a comma separated list of paths to the license files inside the container.

I think it would make sense to ask some guys who actually provide "official" container images what they think about this and if it's feasible to provide the labels.

On Mon, Jun 27, 2016 at 5:34 PM, Tomas Tomecek notifications@github.com wrote:

The label could contain path to the license text; or it could be named ApplicationLicense to indicate that the field doesn't license every bit of the image.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/projectatomic/ContainerApplicationGenericLabels/issues/71#issuecomment-228782540, or mute the thread https://github.com/notifications/unsubscribe/ARrIW0kQL6a0Od0NBxTIUA5MukHBYBU0ks5qP-1pgaJpZM4I-7-I .

Daniel Fröhlich Solution Architect Middleware OpenGroup Certified Master IT Architect

Mobile: +49 176 10 24 84 33 Phone: +49 711 96 43 71 44 E-Mail: daniel.froehlich@redhat.com

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander

TomasTomecek commented 8 years ago

I've just realized that there already was a license label and I'm sort of responsible for its removal: https://github.com/projectatomic/ContainerApplicationGenericLabels/issues/2. There's also this PR which touches the topic.

Since I'm not a maintainer of this repo, it would be nice to get some opinions from the actual maintainers: @rhatdan @aweiteka. For getting feedback from images maintainers, I suggest asking @hhorak.

hhorak commented 8 years ago

I don't see any value in the License field, where would be 100+ licenses listed. The image is something like ISO, where we also do not need to solve license metadata, do we? Anyway, I think this is more a question for a legal expert.

DanielFroehlich commented 8 years ago

Today, I grepped for "license" in my local openshift demo setup which contains ~300 image layers. In total, I could find ~180 unique different license files. You are right, there are images with a lot of licenses, but also images with just a few of them.

The added value from a license list (even if it would be long) would be that you could easily apply e.g. a blacklist.

Yes, it is like ISO images, and we should address the issue there, too (e.g. with a LICENSES.txt in toplevel dir).

I agree that this is a question for a legal experts. Actually, the question is coming from a customer legal expert who has the problem of not being able to start his work, because it is so complicated to find all the licenses inside a container.

So I think we should not close our eyes on this problem but address it in an open and responsible way.