Re: [gentoo-dev] LICENSE and revbumps
Should LICENSE changes require a revision bump? No, since it would be a waste of users' resources. For example, if a dev has missed a change from GPL-2 to GPL-3 (which I guess is a common case), would you really have users reinstall the package in this case? What would be the benefit? Ulrich
Re: [gentoo-dev] LICENSE and revbumps
On Wed, 27 Aug 2008 08:10:06 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: Should LICENSE changes require a revision bump? No, since it would be a waste of users' resources. For example, if a dev has missed a change from GPL-2 to GPL-3 (which I guess is a common case), would you really have users reinstall the package in this case? What would be the benefit? As an example, the user is developing a program under a licence compatible with GPL-3 but incompatible with GPL-2, he wants to extend it with the functionality provided by this library (lets assume the package in question is a library) and he is considering to statically link some bits from it. Now he can do the right way and read the whole web page from that package and learn all about it and all the other candidates, or just first apply a quick filter by checking the LICENCE file and then decide to look for another candidate. I personally would would go with the filtering approach to narrow my search and reduce the time I need to spend looking. As Another example, the user might statically link bits of the exact same library against a GPL-2 (not a GPL-2 or latter) program, just because he is misinformed by portage that the program is GPL-2 and then he gets into a legal problem. so, my point is that licences are very important in some environments and to some people, and having an inconsistently can cause serious legal problems to users. So it is very important to keep them in sync in all tree of upstream, portage tree and vdb tree. Yuri.
Re: [gentoo-dev] LICENSE and revbumps
Yuri Vasilevski a écrit : so, my point is that licences are very important in some environments and to some people, and having an inconsistently can cause serious legal problems to users. So it is very important to keep them in sync in all tree of upstream, portage tree and vdb tree. And people who are really worried about licensing issues should not even *look* at the LICENSE data which can be seriously out-of-date/wrong if maintainers are not careful enough. Furthermore, for a lot of packages, only the major license is described in the ebuild, leaving the minor licenses out : - main software is GPL - library is LGPL - images/icons are CC-SA - doc/man are GFDL, ... As for the original question: I don't think a license change warrants a rebuild for end users. It's just a waste of bandwidth and CPU cycles. Cheers :) -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [gentoo-dev] LICENSE and revbumps
Ryan Hill wrote: On the other hand, it also seems completely ridiculous from a practical POV to have to wait 30 days (and waste arch team resources) to fix an incorrect licence on a stable package. And have everyone recompile the package, thus wasting cpu cycles and users' time. I would have to imagine that if upstream changed the license that the old installation would be covered by the old license. What do binary distributions do if an upstream changes the license? ;) Or are we talking about dev error here? -Jeremy
[gentoo-dev] LICENSE and revbumps
I have an interesting (to me anyways) question.
Should LICENSE changes require a revision bump?
It kinda seems to me the answer should be yes. I don't know if any PM
currently implements LICENSE filtering so there may not be any
technical reason for it yet. And so I guess it comes down to a
philosophical question - what determines the licence(s) a currently
installed package is covered by? My thought is that this would be the
value in /var/db/pkg/${P}/LICENSE, being the LICENSE value at install
time, and therefore a change in the tree requires reinstallation to
change that value.
On the other hand, it also seems completely ridiculous from a practical
POV to have to wait 30 days (and waste arch team resources) to fix an
incorrect licence on a stable package.
Thoughts?
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] LICENSE and revbumps
On Tue, 26 Aug 2008 20:17:48 -0600
Ryan Hill [EMAIL PROTECTED] wrote:
Should LICENSE changes require a revision bump?
A licence changes what get's installed, ok the files are the same, but
the meaning of having the same files is different. So I say yes.
It kinda seems to me the answer should be yes. I don't know if any PM
currently implements LICENSE filtering so there may not be any
technical reason for it yet. And so I guess it comes down to a
philosophical question - what determines the licence(s) a currently
installed package is covered by? My thought is that this would be the
value in /var/db/pkg/${P}/LICENSE, being the LICENSE value at install
time, and therefore a change in the tree requires reinstallation to
change that value.
Correct.
On the other hand, it also seems completely ridiculous from a
practical POV to have to wait 30 days (and waste arch team resources)
to fix an incorrect licence on a stable package.
I think it should be sensible to make the stabilization request a lot
earlier specifying the reason behind the creation of that newer
revision in the bug and the stabilization process should be pretty much
automatic, without wasting to much time from arch teams.
On the other hand, I think it would be wise to create an explicit
exception for this case in stabilization rules and to allow the uploader
of the corrected ebuild to keep the same KEYWORDS instead of
downgrading them to unstable.
Kindest regards,
Yuri.
Re: [gentoo-dev] LICENSE and revbumps
On Tue, 26 Aug 2008 20:17:48 -0600 Ryan Hill [EMAIL PROTECTED] wrote: Should LICENSE changes require a revision bump? No. Any ebuild should be published with a correct reference to a license. If you initially publish the ebuild with a bad reference, you simply correct it later on. It's not as if *you* incorrectly published the software anew - you just tagged on the wrong license initially, and by referring to the wrong license, you aren't somehow magically relicensing the software. As for the technical bit - when a user cannot install something because the license is masked by his package manager, and he discovers that the wrong license was attached, then he can do and should do two things: 1) notify the ebuild's maintainer(s) that the wrong license is being referred to. 2) unmask the license, confident that the reference in the ebuild is wrong, now that he's personally checked it. Kind regards, JeR
