On Thu, Jan 2, 2014 at 10:25 AM, Michael Orlitzky <m...@gentoo.org> wrote: > If you think the transition period for that is long, how long do you > think it will take for people to become aware of the magic USE flag and > begin populating the other-LICENSE-contained-within-LICENSE variable? > How long until it has 100% coverage?
Well, there is no guarantee that the existing LICENSE field is 100% accurate. In fact, the whole reason this came up was that somebody noticed some issues with a package. > > If maintainers don't use it, the feature is useless, because you can't > rely on it and have to audit everything yourself anyway. For it to > actually serve its purpose (e.g. to be useful for Pentoo), it would need > to be in the PMS and skel.ebuild where people have to pay attention to > it. How well would ACCEPT_LICENSE work if LICENSE was optional and > controlled by a USE flag? Well, LICENSE IS controlled by a USE flag - that's the point. We would simply announce the change and update the devmanual and if a maintainer doesn't comply it is a bug, just like if they stick "GPL" on a package that is really proprietary. > > If I intend to automatically redistribute the source tarballs that > portage downloads, I have a few options: > > 1. Audit everything myself (impossible) > 2. Ignore the licensing issues (used in practice) > 3. Only ship packages that declare an acceptable source > distribution license > > There's no easy way to do (3) when using conditionals inside of LICENSE. > If there's a new required license variable in EAPI=$next, however, it > becomes tractable. Sure you can - just use the conditional inside the license. If you don't trust that, then I don't know why you're trusting the LICENSE field at all. No law of nature makes it infallible. Sure, you could have a SRCLICENSE field and 99% of ebuilds could contain SRCLICENSE=$LICENSE just like 99% of them contain DEPEND=$RDEPEND. That doesn't make it any more or less accurate - we have bugs in dependencies all the time, and we'll have bugs on licenses all the time too. The key is that we do due diligence and fix them when we find them. Rich
