doc/licenseAgreement.html explicitly forbids redistribution: The End-User may NOT sublicense, assign, or distribute copies of the Software to others. The Software contains trade secrets. The End-User may NOT decompile, reverse engineer, disassemble, or otherwise reduce the Software to a human readable form. THE END-USER MAY NOT MODIFY, ADAPT, TRANSLATE, RENT, LEASE, LOAN, RESELL FOR PROFIT, DISTRIBUTE, OR OTHERWISE ASSIGN OR TRANSFER THE SOFTWARE, OR CREATE DERIVATIVE WORKS BASED UPON THE SOFTWARE OR ANY PART THEREOF, EXCEPT AS EXPRESSLY PROVIDED IN SECTION 1.C. ABOVE. Therefore the ebuild needs RESTRICT="bindist mirror", and sources must not be hosted on Gentoo mirrors. @sping: Assigning to you because you broke it in bug 288717. ;-)
Created attachment 330242 [details] License of the package And of course, LICENSE should be updated. Plain text version doc/licenseAgreement.html is attached.
As you know the upstream download is dead. If no one can legally distribute copies (including us), the only true fix might be to remove the package from the tree. What do you think?
(In reply to comment #2) > As you know the upstream download is dead. If no one can legally distribute > copies (including us), the only true fix might be to remove the package from > the tree. What do you think? That's what I would conclude too, although it's unpleasant. Otherwise, this can only be resolved by contacting the copyright owner (and IMHO we would be well advised to remove the file from our mirrors before doing so). CCing trustees: We have several other packages that might come to a similar end, see the blockers of tracker bug 436214. Any advice how to proceed in such cases?
(In reply to comment #3) > (In reply to comment #2) > > As you know the upstream download is dead. If no one can legally distribute > > copies (including us), the only true fix might be to remove the package from > > the tree. What do you think? > > That's what I would conclude too, although it's unpleasant. Otherwise, this > can only be resolved by contacting the copyright owner (and IMHO we would be > well advised to remove the file from our mirrors before doing so). > > CCing trustees: We have several other packages that might come to a similar > end, see the blockers of tracker bug 436214. Any advice how to proceed in > such cases? Not a formal response - just my two cents: At the very least we should restrict fetch/mirror as appropriate. If somebody wants to maintain it for the sake of those who have binaries (obtaining them legally is their problem) they are welcome to do. If the package is maintainer-needed and doesn't really have a future then treeclean it. The license should be updated to be accurate if it is kept. Am I missing some nuance here? In this case if we don't have a valid SRC_URI then can we just restrict fetch/mirror? We shouldn't be keeping the files on the mirrors. If there is a technical issue involved then we should do what we need to do to avoid re-introducing the files to mirrors and then purge the file via some other means. I think we can be pragmatic on that bit.
In my understanding, if the download is served from a gentoo.org machine we are distributing the file ourselves, restrict "mirror" may reduce but not solve the problem, restrict "fetch" does not seem to affect the case in my eyes. I do not object to adding either if you see it helps. I just wonder if there is a legally sound way to keep it at all.
(In reply to comment #5) > In my understanding, if the download is served from a gentoo.org machine we > are distributing the file ourselves, restrict "mirror" may reduce but not > solve the problem, restrict "fetch" does not seem to affect the case in my > eyes. I do not object to adding either if you see it helps. I just wonder > if there is a legally sound way to keep it at all. No, the file needs to come off the mirrors - a mirror:// SRC_URI cannot be used for anything for which we do not have a explicit distribution license in writing. Any FOSS license will of course work, but obviously this is not one. There is no legal reason that you can't still have an ebuild for it, though the SRC_URI will just have to be a filename if you can't find a legal distributor, and it will then have to be fetch/mirror restricted.
My vote for complete removal. I guess it will not be missed much. Any objections? Shall we do the usual "last rites" mailing thing?
(In reply to comment #7) > My vote for complete removal. I guess it will not be missed much. Any > objections? Shall we do the usual "last rites" mailing thing? I'd suggest to package mask it, remove the distfile from Gentoo hosts, and send lates rites. If there's any user who has enough interest in it, then he can still make an attempt to contact upstream and sort out the licence issue with them, in which case we could revive the package.
(In reply to comment #8) > I'd suggest to package mask it, remove the distfile from Gentoo hosts, and > send lates rites. If there's any user who has enough interest in it, then he > can still make an attempt to contact upstream and sort out the licence issue > with them, in which case we could revive the package. Full ack, starting the process.
I just have .. - masked the ebuild for removal - added a fetch restriction - sent the last rites mail in that order. Looking at woodpecker:/space/distfiles-local I cannot find profiler.jar anymore already. Am I looking at the wrong place? Also, my understanding is that RESTRICT="fetch" is just right. If you see use for an extra RESTRICT="mirror" though, I can add that for you.
(In reply to comment #10) > Looking at woodpecker:/space/distfiles-local I cannot find profiler.jar > anymore already. Am I looking at the wrong place? That's normal, files disappear from distfiles-local some time after they've been uploaded (something like two weeks IIRC). But the distfile will go away from mirrors if the ebuild is now fetch restricted. > Also, my understanding is that RESTRICT="fetch" is just right. If you see > use for an extra RESTRICT="mirror" though, I can add that for you. "fetch" should imply "mirror", at least that's what ebuild(5) says. An additional "bindist" couldn't harm, though.
(In reply to comment #11) > "fetch" should imply "mirror", at least that's what ebuild(5) says. An > additional "bindist" couldn't harm, though. No objections, just added. + 27 Nov 2012; Sebastian Pipping <sping@gentoo.org> profiler-1-r1.ebuild: + Add bindist restriction on top (bug #444332) +
dropped # Sebastian Pipping <sping@gentoo.org> (27 Nov 2012) # Masked for removal in 30 days. # Licensing issues, turned out not distributable (bug #444332) app-admin/profiler
