Since the Java team switched from 'old style' to 'new style' virtuals, there have been a number of questions / confusion about virtuals in general. I think it would be beneficial to have documentation, both for users and devs, about virtuals. I asked in #-doc, and was informed that it wasn't really documented very well, as in only in the virtuals files themselves, only by passing in the dev handbook, and only briefly discussed in the devmanual. I was advised to assign it to devrel by curtis119.
There seems to be a fair amount of stuff on virtuals added to the handbook since this bug was written....
nichoj, are you satisfied with the handbooks inclusion of virtuals currently so we may close the bug?
Here's what I see now for virtuals documentation: User: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1&style=printable Developer: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1 The user stuff is probably sufficient. The developer stuff looks a little crufty, as it only talks about the 'old-style' virtuals.
I think the requested documentation should be in the developer manual, once there we will remove it from the developer handbook (which is going more towards policy.)
Created attachment 135934 [details, diff] A start atleast Here is at least a start to this bug. One thing that needs to be resolved (can't remember who exactly brought this up now) is the LICENSE in virtuals. It should probably be the combination of all LICENSES of the packages that can satisfy it, that way ACCEPT_LICENSE would work correctly on it. Please correct me if I'm not making sense.
LICENSE should be empty, and repoman should be fixed to accept explicit LICENSE="". Virtuals don't require accepting any licenses themselves.
(In reply to comment #6) > LICENSE should be empty, and repoman should be fixed to accept explicit > LICENSE="". Virtuals don't require accepting any licenses themselves. > Sounds perfectly reasonable. ACCEPT_LICENSE should then automatically accept something that lacks a license then? Just want to make sure we get it documented clearly somewhere.
(In reply to comment #7) > ACCEPT_LICENSE should then automatically accept something that lacks a license > then? It should... Don't know if it does, but it should.
LICENSE="as-is" is perfectly acceptable, too. Of course, if you wanted to get pedantic about the thing, it should probably be GPL-2 since the "virtual" itself is a Gentoo product, and therefore falls under our normal licensing.
Neither as-is nor GPL-2 makes sense. The virtual itself is an empty package, and thus has no licence.
Well, what makes up a virtual is the dependency information provided. As I see it, the ebuild itself *is* the virtual, since the ebuild itself provides everything. We specifically didn't want ACCEPT_LICENSE to allow blank LICENSE, or to have any sort of wildcard capabilities. Everything must have a license. If there is no license giving us the rights to use the code, then copyright takes over and we're not allowed to redistribute it. Without copyright assignment, this even covers Gentoo-created code. There's tons and tons of discussion on it, on the gentoo-dev/gentoo-nfp mailing lists, and also in a bug or two. I'd link to them all, but I'm being lazy... ;]
Well, if everything needs to have a license, then the virtual ebuild needs to list all of the licenses of the packages that can satisfy the virtual, like I originally brought up. Chris: I'll look around and see what I can find on mailing lists or documented elsewhere on the behavior of ACCEPT_LICENSE and what is allowed for the LICENSE variable.
Chris: You're confusing the licence of the ebuild with the licence of the virtual. They're two entirely different things, even when the ebuild installs nothing. We don't stick LICENSE="GPL-2" in ebuilds for non-GPL-2 things, despite the licence terms of the ebuilds. By extension, it shouldn't be added to the licence of a virtual ebuild merely because of the ebuild's metadata. The only sensible solution here is for virtuals to have LICENSE="", and to make repoman accept that. ACCEPT_LICENSE should accept LICENSE="", since there is no license to accept for the package, in the same way that the resolver accepts DEPEND="" as resolved, since there are no dependencies to accept for that package. (Note that LICENSE is like DEPEND, not KEYWORDS, in that it's an all-of resolution except where any-of blocks are in effect, whereas KEYWORDS is an any-of resolution.) Now, you could argue that the tree itself should have an explicit metadata license of some kind, and that users should have to accept the tree's license. But that's an entirely separate issue.
(In reply to comment #13) > Chris: You're confusing the licence of the ebuild with the licence of the > virtual. They're two entirely different things, even when the ebuild installs > nothing. I know what I was saying. I was not confusing the two. Unlike other packages, new-style virtuals are a special case. The old-style "virtuals" are GPL-2 by virtue of being in the profiles, which are all GPL-2. We specifically decided on two things with the ACCEPT_LICENSE stuff. One, is that all ebuilds (and as such, packages) *must* have a license, making LICENSE="" invalid for our usage. This is simply because something without a license falls under copyright and is then restricted from redistribution without the express consent of the copyright holder. Second, that ACCEPT_LICENSE="*" (or other wild cards) were invalid. A package must have a license. If it exists in the tree, there has to be something to it, even if it is just metadata. As such, that data *must* have a license if we're planning on shipping it. Since Gentoo-produced code is licensed under the GPL-2, it should be GPL-2. I'd honestly accept any license which would be suitable, such as "freedist" or "as-is" or even some indication that it is public domain. However, it *needs* some kind of license. That being said, the virtual doesn't need to list the LICENSE of each possible providing package. After all, if I have a GPL-2 package and a CDDL package which provide the same functionality, I don't need to accept the CDDL license to install the GPL-2 package. Ciaran is exactly correct in that the license of the virtual is independent of the licenses of its children. All I am saying is that the virtual *must* have a license. This can be argued ad nauseum, but in the end, the Foundation is going to do what it feels is necessary to cover its own ass, even if said means are *more* than required by law. It is better to be safe than sorry. US copyright law is fairly simple. If you don't have express permission to redistribute from the copyright holder, you have *no* right to redistribute whatsoever. Since we don't have a proper legal copyright assignment system, we would have to ask the individual copyright owner of the virtual for permission and keep that on file somewhere. I think it is much easier to just assign a license to the virtual, even if you feel that it is unnecessary to do so, for the reasons stated above.
Chris: Your argument is entirely invalid since the virtual isn't distributing anything. The LICENSE keyword only applies to the things installed by the package (and not including any Gentoo-authored metadata). Thus, in this specific case, LICENSE="" is correct, and the only thing the Foundation needs to care about is the usual ebuild copyright assignment and licensing.
I have to agree with Ciaran on this one. We already have the license for the "ebuild" at the top, which is what you seem to be talking about Chris. Since the virtual doesn't install anything besides the metadata that we already have a GPLv2 on, I don't see the purpose of putting anything into LICENSE. And if we need to put a license in the variable, its going to have to be the possible licenses for all packages that can satisfy that virtual, otherwise I can't see any sane way that ACCEPT_LICENSE would allow that virtual to be installed. (someone correct me if I'm mistaken here)
(In reply to comment #16) > Since > the virtual doesn't install anything besides the metadata that we already have > a GPLv2 on, I don't see the purpose of putting anything into LICENSE. Please explain this. If the metadata that we're installing is covered under the GPLv2, why would that not cover the package, too? If it does, then the package is GPL-2 and should have an appropriate LICENSE. > And if we need to put a license in the variable, its going to have to be the > possible licenses for all packages that can satisfy that virtual, otherwise I > can't see any sane way that ACCEPT_LICENSE would allow that virtual to be > installed. (someone correct me if I'm mistaken here) This is incorrect for one reason. New-style virtuals are packages. The license of the virtual is the license for the virtual, not for every single package the virtual could *possibly* install. As I said, I don't need to accept CDDL to install a GPL-2 application. At the same time, with the new-style virtuals, most things depend on the virtual, not what the virtual provides, so I could see a situation where someone could get the virtual package but not the actual package due to license restrictions/masks. At any rate, its become a bit obvious that I'm not getting my point across. As such, I'll simply defer any decision/discussion once it comes up to the Foundation and let consensus take over.
(In reply to comment #17) > (In reply to comment #16) > > Since > > the virtual doesn't install anything besides the metadata that we already have > > a GPLv2 on, I don't see the purpose of putting anything into LICENSE. > > Please explain this. If the metadata that we're installing is covered under > the GPLv2, why would that not cover the package, too? If it does, then the > package is GPL-2 and should have an appropriate LICENSE. The metadata for every package, if it is copyrightable, is GPL-2, yet we do not stick LICENSE="GPL-2" for every package because the metadata is covered by the tree's (not explicitly accepted and outside of the scope of LICENSE / ACCEPT_LICENSE) license. > At any rate, its become a bit obvious that I'm not getting my point across. We all understand your point. It's just wrong.
Portage team: Comments and input on how this is currently implemented, and how we want this to work?
a) virtuals should not have a value in LICENSE for reasons stated above (unless they actually install something to $ROOT) b) an empty value for LICENSE doesn't mask an ebuild
Created attachment 136923 [details, diff] Added in the LICENSE blurb Added in a small blurb about setting the LICENSE variable to an empty string. Anyone see anything wrong with this?
Created attachment 136931 [details, diff] make repoman ignore empty LICENSE for "virtual" category
Wouldn't above-mentioned arguments apply to HOMEPAGE as well?
(In reply to comment #23) > Wouldn't above-mentioned arguments apply to HOMEPAGE as well? > Good point. Lets do that too. I'll update the doc tomorrow (way too tired to do so now). Zac: do you agree? And can you add that into the repoman check if so. Thanks
(In reply to comment #24) > Zac: do you agree? And can you add that into the repoman check if so. Yes, the current ~arch version of portage ignores both missing HOMEPAGE and LICENSE.
I think it's worth mentioning self-blocking virtuals which is the only reason why old style cannot be deprecated. also in the new style section it might be worth saying explicitly that they are regular packages with any-of runtime dependencies..
One additional feature the new style virtuals do not have (yet) is the ability to set a preference in the profile without necessarily pulling the package into the system set (accomplished with old style virtuals via the "virtuals" file in the profile). For an example of how this can be useful, see bug 161953.
Just added this to devmanual. If you find anything wrong with it, please hit me with the cluebat and add QA back to this bug. We are done as far as I can tell. Not sure if devrel wants to do anything additional with regards to the dev handbook.
http://devmanual.gentoo.org/general-concepts/virtuals/ The running text says: "a new-style virtual has an empty string for the value of the LICENSE and HOMEPAGE variables" while the example has a non-empty HOMEPAGE. Shouldn't this be made consistent?
(In reply to comment #29) > http://devmanual.gentoo.org/general-concepts/virtuals/ > The running text says: "a new-style virtual has an empty string for the value > of the LICENSE and HOMEPAGE variables" while the example has a non-empty > HOMEPAGE. Shouldn't this be made consistent? > Yea, oops...I suck :) Thanks
QA is done here.
Is there anything more that could be changed in current devmanual?
