[gentoo-dev] Package up for grabs: dev-python/pybluez
Hello, The Python team no longer wishes to maintain the following package: dev-python/pybluez It has no tests, and it'd be better for it to have a dedicated maintainer with working bluez and possible a use case for one of its reverse dependencies: app-mobilephone/ganyremote app-mobilephone/wammu kde-misc/kanyremote There's an open version bump request, missing dep bug and the package needs testing with newer Python versions. However, all revdeps are py2.7-only. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-mobilephone/lightblue
# Michał Górny (2020-01-31) # Last release in 2009. No tests. Python 2 only. No reverse # dependencies. # Removal in 30 days. Bug #707550. app-mobilephone/lightblue -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
On Thu, Jan 30, 2020 at 8:39 AM Hanno Böck wrote: > > *If* Gentoo decides to go this relicensing way I'd recommend to only do > that if it's coordinated with organizations that have deep legal > knowledge of these issues (e.g. like software freedom conservancy) and > if some lawyers that know this stuff well approve the plan. > IMO no organization has "deep legal knowledge" of these issues, because as far as I'm aware something like this has never been done and tested in court. Really there are only a handful of legal cases at all that deal with copyleft and FOSS relicensing. There is no end of lawyers who will hand-wave on the issue. I think the bottom line is that doing something like this is legally risky, because until something like this has been done successfully many times it is novel. You're never going to find a lawyer who will sign off saying "this is safe and definitely legal." The only way you could make something like this risk-free would be to get governments around the world to pass laws setting up requirements for FOSS-relicensing without the consent of all contributors. The best we can do is mitigate risks, if we elect to do something like this. That can include being transparent, giving notice, having a way to opt out, and so on. Then when somebody sends us a cease and desist notice we just tell them no problem, their contributions will be treated as v2-only. That doesn't completely prevent them from suing us, but it would mitigate the impact, and probably make it unlikely that most would sue in the first place. Really, with something like this that is the best you're ever going to be able to hope for. If you don't want to do something unless a lawyer can guarantee that it can't be found to be a tort by a court, then you definitely don't want to pursue this change, unless we only make it forward-going for new contributions and carefully track existing code, and I doubt that will ever be very practical, so you might as well just give up and say we'll be v2 forever because that's how things were set up 20 years ago. -- Rich
Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
I'm a bit worried if we should really go down that path. Not because I have issues with GPL2+ (I'm usually happy with everything that makes licensing more flexible), but because I'm worried we're creating a legal minefield. Think about this: You may ask me if you can relicense all the ebuilds I've ever written as GPL2+. I'll say yes. Though ask me if you can relicense all the ebuilds I've ever committed? Well... They came from bug reports, overlays, heavily edited by other people, and I have no way of tracking that. I added them under the implicit assumption that someone who has submitted such an ebuild to bugzilla or to an overlay with the gentoo/gpl2 copyright line in it would implicitly agree that they would be redistributed under those conditions. IANAL, but I think that's a fair assumption. But do all these people that created or contributed to the ebuilds I ever committed agree to a GPL2+-relicensing? No idea, probably not. Is their work relevant enough to have a license at all? IANAL. *If* Gentoo decides to go this relicensing way I'd recommend to only do that if it's coordinated with organizations that have deep legal knowledge of these issues (e.g. like software freedom conservancy) and if some lawyers that know this stuff well approve the plan. -- Hanno Böck https://hboeck.de/ pgpoBtmFxekQw.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
On Thu, Jan 30, 2020 at 6:20 AM Haelwenn (lanodan) Monnier
wrote:
>
> [2020-01-27 12:41:26+0100] Ulrich Mueller:
> > So, the question is, should we allow ebuilds
> > # Distributed under the terms of the GNU General Public License, v2 or later
> > in the repository, or should we even encourage it for new ebuilds?
> >
> > I have somewhat mixed feelings about this. One the one hand, I think
> > that GPL-2+ should generally be preferred because it offers better
> > compatibility. For example, the compatibility clause in CC-BY-SA-4.0
> > won't work with GPL-2.
>
> Is there another reason for GPL-2+ than just compatibility?
> Because I quite find the "or later" thing to be quite a scary one as
> whatever will come up next as a GPL will become applicable and it feels
> quite weird to me to have a license that can evolve to whatever
> license over time.
Well, there are two sides to this particular issue.
GPL 2+ means that anybody can choose to redistribute the code under
the terms of any version of the GPL that is >=2. So, if they add
terms to GPL v4 that you really don't like, you can still redistribute
it under the terms of GPL v2-3 if you prefer.
The other side to this is that you can't stop others from
redistributing it under v4. They could also incorporate it into other
code that is v4+ which you could only redistribute under v4 or
greater. Of course, the original code can still be redistributed
under v2 - it is just the parts that are comingled with other v4 code
that is at issue.
Really the main threat (IMO) is that the code could be de-copylefted.
They could make GPL v4 a copy of the BSD license, and now anything
that was v2+ is effectively BSD and can be used in non-FOSS software
without issue. I guess that isn't any worse than the previous case of
it instead being merged into some other v4 variant that you can access
the source for but prefer to avoid because of something else in the
license, except now you might not see the code at all.
The advantage of 2+ is of course flexibility:
For one it reduces license proliferation. Code that is v2-only is
effectively orphaned with regard to v3, v4, v5, and so on projects in
the future. GPLv2 is fairly restrictive by design around
compatibility with other licenses and accepting future versions helps
mitigate this insofar as you trust the FSF.
And of course if at some point some fatal flaw is found in the GPL in
a court case, it is possible that a future version could mitigate that
flaw. Of course, if that flaw lets anybody ignore the copyleft bits
you can't prevent people from using it under the old flawed v2, but at
least you can still use the code in your own v4 or whatever. Of
course, if the flaw effectively made the v2 code public domain you can
do that anyway, but if the flaw were of a different nature it might
cause problems having code being locked up as v2-only.
>
> I think I would personally slightly prefer to have it be properly
> dual-licensed GPL-{2,3} or GPL-2 & CC-BY-SA-4.0 instead.
>
The problem like this is that this is basically just kicking the can
down the road. It is of course equivalent for the moment, but when
GPLv4 comes along we have to go through this again. Right now most of
the Gentoo authors are alive and might be willing to explicitly sign
off on a relicense (maybe). However, maybe in another 10 years when
GPLv4 comes out it is going to be much harder to track everybody down.
On the flip side the fact is that none of us know what the FSF will
look like in 10 years, or 40 years. There are plenty of large
non-profits today that bear little resemblance to what they looked
like 100 years ago, for good or ill. The GPL v2 (or v3) are known
quantities that we can debate on in a concrete manner, but unknown
future versions can only be speculated on.
Another solution to this problem is the FLA - which is something we've
talked about but shelved until we've sorted out some of our other
copyright issues which were thorny enough. Perhaps we could consider
taking that up again. Without getting into the details it is a bit
like a copyleft-style copyright assignment, which isn't actually an
assignment. We envisoned it being voluntary and would allow any
contributor to give the Foundation the authority to relicense their
contributions, with a number of restrictions, like the new license
being FOSS. I'd have to dig up the latest version and take a look at
it again. Basically instead of trusting the FSF you'd be trusting the
Foundation instead, but there are some limitations on what they'd be
allowed to do, and if they violate those limitations the agreement
would be canceled and the rights would revert back to whatever was on
the original contribution, which would probably be whatever the author
originally wanted. That said, I'm not sure it really provides a whole
lot more protection over what happens except for the fact that
Foundation members have more say in how the Foundation operations than
the FSF, if only because
Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
[2020-01-27 12:41:26+0100] Ulrich Mueller:
> So, the question is, should we allow ebuilds
> # Distributed under the terms of the GNU General Public License, v2 or later
> in the repository, or should we even encourage it for new ebuilds?
>
> I have somewhat mixed feelings about this. One the one hand, I think
> that GPL-2+ should generally be preferred because it offers better
> compatibility. For example, the compatibility clause in CC-BY-SA-4.0
> won't work with GPL-2.
Is there another reason for GPL-2+ than just compatibility?
Because I quite find the "or later" thing to be quite a scary one as
whatever will come up next as a GPL will become applicable and it feels
quite weird to me to have a license that can evolve to whatever
license over time.
I think I would personally slightly prefer to have it be properly
dual-licensed GPL-{2,3} or GPL-2 & CC-BY-SA-4.0 instead.
Re: [gentoo-dev] Last rites: dev-python/epydoc
On Thu, 2020-01-30 at 06:18 +0100, David Haller wrote:
> Michal, ...
>
> On Wed, 29 Jan 2020, Michal Górny wrote:
> > # Michal Górny (2020-01-29)
> > # Abandoned in 2009. Python 2 only. No blockers left.
> > # Removal in 30 days. Bug #706218.
> > dev-python/epydoc
>
> ... I think you're getting a liiittle bit trigger happy there ...
>
> # equery d dev-python/epydoc
> * These packages depend on dev-python/epydoc:
> sys-apps/portage-2.3.86 (python_targets_python2_7 ? >=dev-
> python/epydoc-2.0[python_targets_python2_7(-)?,-
> python_single_target_python2_7(-)])
>
>
> $ cd /usr/portage/sys-apps/portage
> $ grep epydoc portage-2.3.86.ebuild
> IUSE="build doc epydoc gentoo-dev +ipc +native-extensions +rsync-
> verify selinux xattr"
> epydoc? (
> >=dev-python/epydoc-2.0[${PYTHON_USEDEP}]
> REQUIRED_USE="epydoc? ( $(python_gen_useflags 'python2*') )"
> use epydoc && DISTUTILS_ALL_SUBPHASE_IMPLS=( python2.7 )
> use epydoc && targets+=( epydoc )
> use epydoc && targets+=(
> install_epydoc
>
>
> ... and thats the fricking bleeding edge unstable portage, mind!
> Stable 2.3.84-r1 looks almost identical when grepped ...
>
> BTW: has it been taken note of that (at least ESR) Mozillen like
> firefox still use python2.7 for quite a bit in the build process?
>
> -dnh
>
Portage is working on replacing their documentation with sphinx. Is a
missing USE="doc" breaking your system?
