Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Add a License Label #71

Open
DanielFroehlich opened this issue Jun 27, 2016 · 7 comments
Open

Proposal: Add a License Label #71

DanielFroehlich opened this issue Jun 27, 2016 · 7 comments

Comments

@DanielFroehlich
Copy link

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
Copy link
Contributor

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
Copy link
Author

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
#71 (comment),
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
Copy link
Contributor

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
Copy link
Author

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
#71 (comment),
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
Copy link
Contributor

I've just realized that there already was a license label and I'm sort of responsible for its removal: #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
Copy link
Contributor

hhorak commented Jun 28, 2016

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants