Re: Licensing change: Audacious - GPLv3 --> BSD
Hi. On Mon, 9 Jul 2012 13:10:48 + (UTC), Petr Pisar wrote: > How could they have changed the license without asking contributors? > I have periodically translated the messages, I believe I have some > patches there and nobody had asked me. I did get asked about some (rather trivial) functions I added to the core years ago, so there was an effort to do this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: intel ipw2100/ipw2200 firmware must be removed
Hi. On Sun, 8 Jul 2012 16:16:31 -0600, Kevin Fenzi wrote: > See: > http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Binary_Firmware Question about that: The first requirement is that the file is non-executable. Does that mean that Fedora cannot ship firmware for hardware that has a CPU compatible with the host CPU? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On 07/06/2012 09:55 PM, Bill Nottingham wrote: Package svnmailer (orphan) I've taken svnmailer in all branches. Co-maintainers very welcome (hint). Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On 2012-07-09, Michael Schwendt wrote: > On Mon, 9 Jul 2012 13:10:48 + (UTC), Petr Pisar wrote: > >> > As of 3.3-beta1, Audacious is now officially under a two-clause BSD >> > license (previously GPLv3). Some plugins (separate package) are still >> > under other licenses, however. >> >> How could they have changed the license without asking contributors? >> I have periodically translated the messages, I believe I have some patches >> there and nobody had asked me. > > Have you had your name and a copyright statement in any source file? Obviously not. I just remember some patches into plugins and they have been removed probably. > To highlight that you've been the [primary] author of that file? If not, > you're not a full/official author to have a stake in the licensing > decision. > I understand the practical point of view, but I cannot agree from the point of view of law. This aspect has been already discussed and I'm not going to dispute it more. > I see your name in the cs.po file's list of translators. The header says > "This file is distributed under the same license as the Audacious > package." Same for the plugins' translations, but those have never applied > a single license. Because the translation is derived work of message template (*.pot file) which is itself compilation over all source files, each getting its own license. > Each plugin applies an individual license. As with source > code and no accurate attribution, one would need to figure out who of the > multiple translators contributed what portions of the translation. Not really > feasible, IMO. > Yes, but the question here are the translators rights which are, at least in my case, declared clearly in the header of cs/po.cs and also visible in git log of the project: # Petr Písař , 2007, 2008, 2009, 2010, 2011, 2012. I believe five years of creative work is significant portion of the deal to bother project leader to ask translators for permission to change the license terms. In spot of the declaration of another contributor in this threat I think Audacious upstream tracked the C code authors but ommited the translators. (Actually I do not wonder. In recent past, it was difficult to get my updates to upstream, the developers were ignoring my bug reports about out-dated po/POTFILES.in which got the whole project translation effort into deep limb. Audacious developers got tired of the internationalization probably, and they moved the translations to Lunchpad which effectively killed my interrest in translating this project any more. Changing the license to BSD while overlooking translators just confirms their ingorance in this field.) > If you think you've got a stake in the licensing decision, you would > need to talk to the core developers. > > My request for a "License clarification" can be found in the new bug > tracker: http://redmine.audacious-media-player.org/issues/46 > Thanks for the link. I will give them few sentences. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On 07/10/2012 03:20 AM, Orcan Ogetbil wrote: On Mon, Jul 9, 2012 at 3:21 PM, Cosimo Cecchi wrote: On Fri, 2012-07-06 at 16:55 -0400, Bill Nottingham wrote: Removing: raptor flickcurl requires libraptor.so.1 flickcurl requires raptor-devel = 1.4.21-11.fc17 flickcurl-devel requires raptor-devel = 1.4.21-11.fc17 flickcurl-devel requires pkgconfig(raptor) = 1.4.21 liblrdf-devel requires raptor-devel = 1.4.21-11.fc17 librawstudio requires libraptor.so.1 rawstudio requires libraptor.so.1 tracker requires raptor-devel = 1.4.21-11.fc17 Tracker currently has a BuildRequires on raptor-devel, but it's actually an obsolete check, since it dropped the require a couple of years ago. The BR should just be removed from the spec file in this case. Similar situation for liblrdf. It was built against raptor2 but the liblrdf-devel erroneously required raptor-devel. Now I got this fixed. Orcan Orcan, did you want to take on those that you are co-maintaining? If not I'll take them Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dracut-20-51 - Heads up
On Mon, Jul 09, 2012 at 10:54:12 -0400, Marc Dionne wrote: On Mon, Jul 9, 2012 at 10:27 AM, Harald Hoyer wrote: Added an automatic test in the dracut testsuite, so that this never happens again.. Sorry for the inconvenience. Yes, rawhide sometimes eats babies. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Thanks for the heads up... but in my case too late :) One of the effects is that chunks of my / went missing, notably /etc and some other directories that I wouldn't think could be related to this. So I ended up doing a reinstall. Perhaps the corruption is more of a result of ext4 not handling the multiple unclean shutdowns while trying to debug. That happened to me on one of my two rawhide instances. I think I shot myself in the foot while trying to fix things by mounting root read/write when I shouldn't have. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
Hi, On 07/06/2012 10:55 PM, Bill Nottingham wrote: Package vorbisspi (fails to build) Fixed. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, 10 Jul 2012 09:15:19 +0200, Ralf Ertzinger wrote: > Hi. > > On Mon, 9 Jul 2012 13:10:48 + (UTC), Petr Pisar wrote: > > > How could they have changed the license without asking contributors? > > I have periodically translated the messages, I believe I have some > > patches there and nobody had asked me. > > I did get asked about some (rather trivial) functions I added to the core > years ago, so there was an effort to do this. Yes, changing the licensing (also as a consequence of replacing fundamental parts of the code and deleting entire files) had started long ago. Lots of files have had BSD licensing already. And you are one who is credited in a few files and parts of the base player, so it isn't a surprise you've been contacted. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 loadavg: 0.17 0.53 0.29 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, 10 Jul 2012 08:00:50 +0200, Nicolas Mailhot wrote: > > > On Mon, 09 Jul 2012 15:30:50 -0400, Tom Callaway wrote: > > > What if the main creators of the software prefer acknowledging substantial > > contributions with proper attribution and copyright notice in the file > > preambles? > > I don't think what the main creators decide to acknowledge (or not) has > any legal bearing on the copyrightability of past contributions. (don't > like the legal requirements of some work? just don't acknowledge it!) Uh, come on, no smartass comments in this thread! :-( A little bit of familiarity with the development of Audacious (not the plugins!) is necessary, or else the thread will focus on general things that don't really apply. Years ago, the software had started as a fork of BMP, which itself had been a fork of XMMS. Not only one could find copies of the old list of authors shipped with the new project releases, copyright notices were present in (many?) inherited files, too. Either referring to individuals or some "team" name. While working on the source code, the new team has continued to maintain copyright notices but has also introduced new files with different albeit compatible licensing. Eventually, old code for the base software has been replaced/removed completely, and together with deleting files or changing their content 100%, the copyright notices have been replaced, too. I consider it likely and plausible that so much has changed, not much old stuff is left anymore (and this is what the current development team believes, too, according to a history section in the most recent AUTHORS file). Some patch authors are still credited, others may have contributed to BSD licensed project files before. Only they can tell, and only the current main developers can tell the full story. This may be another chance for smartasses to jump in with general legal pedantry, but I don't consider that helpful. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 loadavg: 0.64 0.62 0.39 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, 10 Jul 2012 09:03:02 + (UTC), Petr Pisar wrote: > > Have you had your name and a copyright statement in any source file? > > Obviously not. I just remember some patches into plugins and they have > been removed probably. The plugins are a different source package and a different Fedora package, too. This thread is about the base player. > (Actually I do not wonder. In recent past, it was difficult to get my > updates to upstream, the developers were ignoring my bug reports about > out-dated po/POTFILES.in which got the whole project translation effort > into deep limb. This list is the wrong place to complain about that. The bug tracker has changed end of 2011, but they have been quick in responding to tickets. > Audacious developers got tired of the > internationalization probably, and they moved the translations to > Lunchpad which effectively killed my interrest in translating this > project any more. I think they've moved to using Transifex. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 loadavg: 0.38 0.37 0.43 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On Fri, Jul 6, 2012 at 10:55 PM, Bill Nottingham wrote: > Package devtodo (orphan) I will take this package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Quick rawhide test of libudev debuginfo
If you have the latest Rawhide, could you try the very simple test described in the comment? You will need to install the latest 'systemd' & 'systemd-debuginfo' packages; my suspicion is that the latter is broken. https://bugzilla.redhat.com/show_bug.cgi?id=838793#c2 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: opencv soname bump in upcoming 2.4.1
On 07/04/2012 12:13 PM, Honza Horak wrote: opencv-2.4.1 is already in Rawhide git, but not built yet, which will be done in few days though. Since 2.4.1 bumps soname, the following packages need to be rebuilt: player digikam mrpt fawkes frei0r-plugins gstreamer-plugins-bad-free php-facedetect Unfortunately, I'm not able to do the rebuild by myself, so I'd like to ask maintainers to do so after opencv-2.4.1 is built, which will be announce here as well. I've just pressed the red button and opencv-2.4.2 (yes, even newer version, than has been announced) is now built in rawhide. Please, re-build depending packages. Thanks for collaboration. Cheers, Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Quick rawhide test of libudev debuginfo
Well, false alarm, possibly. It turns out that valgrind won't work yet with the new compressed DWARF that gcc is generating, so something to watch out for if you're using Rawhide. (I also noticed that gdb had problems, although it didn't segfault). https://bugzilla.redhat.com/show_bug.cgi?id=838793#c5 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Mon, 2012-07-09 at 15:30 -0400, Tom Callaway wrote: > On 07/09/2012 03:21 PM, Matthew Garrett wrote: > >> and arbitrary other people, who get their patch contributions merged, > >> > don't gain any copyright protection on the file or the proper parts of > >> > it, > > I don't think this is true. > > Agreed. It is my opinion that this is not the case, assuming that the > changes are substantial enough to be copyrightable. > > I'm otherwise refraining from comment on this thread, because it is > unclear as to whether translations are copyrightable or not. Translated books are certainly copyrightable and have a separate copyright than the original, I do not see why translations of programs should not assuming entire phrases are translated and not single terms. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Exchanging reviews - mine one is leveldb
Hello. I'm again offering a review for trade. You'll review this one and I'll review yours: * https://bugzilla.redhat.com/823170 - leveldb - A fast and lightweight key/value database library by Google This is a C++ library intended for the developers. I added autotools build system and built it as a shared library. It also has known issues on a secondary arches (I'm working on it). The package is one of the requirements for Riak. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: intel ipw2100/ipw2200 firmware must be removed
On 07/10/2012 01:33 PM, Ralf Ertzinger wrote: > Hi. > > On Sun, 8 Jul 2012 16:16:31 -0600, Kevin Fenzi wrote: > >> See: >> http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Binary_Firmware > > Question about that: > > The first requirement is that the file is non-executable. Does that mean that > Fedora cannot ship firmware for hardware that has a CPU compatible with the > host CPU? Do we have any such firmware at all? Let's stick to practical issues. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Exchanging reviews - mine one is leveldb
On Tue, 2012-07-10 at 15:08 +0400, Peter Lemenkov wrote: > Hello. > I'm again offering a review for trade. You'll review this one and I'll > review yours: > > * https://bugzilla.redhat.com/823170 - leveldb - A fast and > lightweight key/value database library by Google > > This is a C++ library intended for the developers. I added autotools > build system and built it as a shared library. It also has known > issues on a secondary arches (I'm working on it). The package is one > of the requirements for Riak. I'll go ahead and take it as I believe ceph is currently bundling this library, and it would be good to get it unbundled. Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On 07/10/2012 07:06 AM, Simo Sorce wrote: > On Mon, 2012-07-09 at 15:30 -0400, Tom Callaway wrote: >> On 07/09/2012 03:21 PM, Matthew Garrett wrote: and arbitrary other people, who get their patch contributions merged, > don't gain any copyright protection on the file or the proper parts of it, >>> I don't think this is true. >> >> Agreed. It is my opinion that this is not the case, assuming that the >> changes are substantial enough to be copyrightable. >> >> I'm otherwise refraining from comment on this thread, because it is >> unclear as to whether translations are copyrightable or not. > > Translated books are certainly copyrightable and have a separate > copyright than the original, I do not see why translations of programs > should not assuming entire phrases are translated and not single terms. I'm not taking sides on this issue, merely pointing out that it is unclear. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On 07/10/2012 05:22 AM, Michael Schwendt wrote: > This may be another chance for smartasses to jump in with general legal > pedantry, but I don't consider that helpful. All accurate legal interpretations are essentially "pedantry". What I don't consider helpful is making broad generalizations about legal issues. Copyright doesn't fail to exist because it isn't attributed. Yes, the copyright situation on a long-lived FOSS project like Audacious is rather complicated. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unable to login to Koji website
Am 09.07.2012 23:17, schrieb Matt Spaulding: > I'm having trouble logging into the Koji website. > > I ran "fedora-packager-setup" on the command line and generated my certs, > including the browser cert for Firefox. I then followed the instructions on > the wiki to import the cert into my browser. > > When clicking "login" on Koji it asks if I would like to use my imported > certificate to log in. After clicking "Ok" the website spins trying to > connect and is not able to do so. > > Did I miss a step? Anyone had this happen? Btw, I am able to use the Koji > command line tool just fine. Same problem here. Starting built processes on koji via cli ain't a problem, but logging in via Firefox and a valid, new certificate doesn't work. Any hints? Regards, vinz. -- Vinzenz Vietzke B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gutenprint update in rawhide, soname bump
On Mon, Jul 09, 2012 at 08:53:14AM -0500, Jiri Popelka wrote: > This soname bump has been an upstream error. > Please rebuild (again) cinepaint and photoprint once this gets into rawhide. > Thanks. Photoprint is rebuilt for rawhide now. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 838679] perl-Plack: EL-6 build
https://bugzilla.redhat.com/show_bug.cgi?id=838679 --- Comment #2 from Xavier Bachelot --- Thanks for the comprehensive summary. Looks like this will be a though one. About the missing PPC64 packages, this is a pain, but that can be dealt with. About the test suites, I think it should be acceptable to selectively disable tests that are failing because of the unmet dependencies. What do you think ? -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, 10 Jul 2012 08:57:52 -0400, Tom Callaway wrote: > On 07/10/2012 05:22 AM, Michael Schwendt wrote: > > This may be another chance for smartasses to jump in with general legal > > pedantry, but I don't consider that helpful. > > All accurate legal interpretations are essentially "pedantry". This mailing-list is impressive at times. Not! :-/ Pedantry alone wouldn't be a bad thing. Lack of accuracy is what makes it bad. Combine pedantry with accuracy, and this thread may become helpful. But instead, there is a lot of speculation and assumptions, and rose-coloured glasses are involved, too. And no IANAL disclaimers seen anywhere. If you really want to contribute "accurate legal interpretations", let's discuss a specific scenario/case. > What I don't consider helpful is making broad generalizations about > legal issues. Copyright doesn't fail to exist because it isn't > attributed. That's a generalization. And a dangerous one. In particular, since we would first need to discuss what requirements a creation must meet to qualify for copyright. That alone is not a simple topic. Also, imagine that both a main developer [of a project] and a patch contributor own copyright on an almost identical work they've created. Such as a code change that involves more than touching a single line, but which may still lead to duplication or high similarity, because multiple people have worked on the same problem coincidentally. If the patch author decides to offer his work to the project, nothing forces the project developer to copy [or adapt] the patch instead of applying the own work, which may be *very* similar or even equal (if it comes to small code changes). One would need to examine the final code changes in detail to decide whether any copying of copyrighted work has been involved and whether that could have been avoided. It boils down to some forms of etiquette, whether and when main project developers recognize contributed patches as substantial and automatically give proper credits *before* a copyright holder wants to enforce rights. It shouldn't be too much to ask for that a contributor explicitly points out what the main developers are expected to do (such as giving credits, adding names to copyright notices, e.g.) when copying or adapting a patch or only parts of it, even if they may just do that to save some time. It could be that more patches would be rejected because they would not be considered substantial enough and not applicable to copyright. There's the loop again. ;) > Yes, the copyright situation on a long-lived FOSS project > like Audacious is rather complicated. +1 That sounds reasonable. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 loadavg: 0.29 0.34 0.34 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 838679] perl-Plack: EL-6 build
https://bugzilla.redhat.com/show_bug.cgi?id=838679 Ralf Corsepius changed: What|Removed |Added CC||rc040...@freenet.de --- Comment #3 from Ralf Corsepius --- (In reply to comment #2) > About the test suites, I think it should be acceptable to selectively > disable tests that are failing because of the unmet dependencies. What do > you think ? This may let packages get away with unnoticed bugs and issues. I'd consider this to be prohibitive, because Plack and its infrastructure are pretty comprehensive and security sensitive. Openly said, based on what I went through on Fedora (A need to closely track the upstream versions of several perl-Plack perl dependency), I do not see much chances of getting Plack into epel6 without major general upgrades to many other epel6 perl-modules (and may-be perl itself). -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
UFS / AFFS filesystems
Hi, Have the ufs / affs and other file systems been intentionally dropped from the F17 kernel, or is that just an oversight? -- Ian Chapman. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120710 changes
Fedora Rawhide Report (rawh...@fedoraproject.org) said: > Compose started at Tue Jul 10 08:15:02 UTC 2012 > > Broken deps for x86_64 > -- > [gnucash] > gnucash-2.4.10-4.fc17.x86_64 requires libofx.so.4()(64bit) > [grisbi] > grisbi-0.8.8-3.fc17.x86_64 requires libofx.so.4()(64bit) > [homebank] > homebank-4.4-3.fc17.x86_64 requires libofx.so.4()(64bit) > [kmymoney] > kmymoney-4.6.2-2.fc18.x86_64 requires libofx.so.4()(64bit) > [skrooge] > skrooge-libs-1.3.0-1.fc18.x86_64 requires libofx.so.4()(64bit) Oops, my bad, didn't catch that the minor update changed ABI. Will fix... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, Jul 10, 2012 at 04:21:12PM +0200, Michael Schwendt wrote: > Pedantry alone wouldn't be a bad thing. Lack of accuracy is what makes it > bad. Combine pedantry with accuracy, and this thread may become helpful. > But instead, there is a lot of speculation and assumptions, and > rose-coloured glasses are involved, too. And no IANAL disclaimers seen > anywhere. Saying things like: "and arbitrary other people, who get their patch contributions merged, don't gain any copyright protection on the file or the proper parts of it," is inaccurate and dangerous. It's entirely appropriate to indicate that it's untrue. > > What I don't consider helpful is making broad generalizations about > > legal issues. Copyright doesn't fail to exist because it isn't > > attributed. > > That's a generalization. And a dangerous one. In particular, since we would > first need to discuss what requirements a creation must meet to qualify > for copyright. That alone is not a simple topic. No we don't. A lack of attribution does not result in copyright failing to exist. The work not being copyrightable in the first place may result in copyright failing to exist, but that has nothing to do with attribution. > It boils down to some forms of etiquette, whether and when main project > developers recognize contributed patches as substantial and automatically > give proper credits *before* a copyright holder wants to enforce rights. It boils down to copyright law. Nothing more. Nothing less. Project maintainers simply don't get to make that choice on behalf of others. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Perl-Critic] Fix breakage with Perl::Tidy ≥ 20120619 (CPAN RT#77977)
commit 7ebd378dc372d774519584051607ccaee7367d92
Author: Paul Howarth
Date: Tue Jul 10 15:52:45 2012 +0100
Fix breakage with Perl::Tidy ≥ 20120619 (CPAN RT#77977)
Perl-Critic-1.117-tidy.patch | 41 +
perl-Perl-Critic.spec| 14 +++---
2 files changed, 52 insertions(+), 3 deletions(-)
---
diff --git a/Perl-Critic-1.117-tidy.patch b/Perl-Critic-1.117-tidy.patch
new file mode 100644
index 000..d8cef24
--- /dev/null
+++ b/Perl-Critic-1.117-tidy.patch
@@ -0,0 +1,41 @@
+See https://rt.cpan.org/Public/Bug/Display.html?id=77977
+
+--- lib/Perl/Critic/Policy/CodeLayout/RequireTidyCode.pm (revision 4123)
lib/Perl/Critic/Policy/CodeLayout/RequireTidyCode.pm (working copy)
+@@ -12,6 +12,7 @@
+ use warnings;
+
+ use English qw(-no_match_vars);
++use IO::String qw< >;
+ use Readonly;
+
+ use Perl::Tidy qw< >;
+@@ -49,7 +50,8 @@
+
+ # Set configuration if defined
+ if (defined $self->{_perltidyrc} && $self->{_perltidyrc} eq $EMPTY) {
+-$self->{_perltidyrc} = \$EMPTY;
++my $rc = $EMPTY;
++$self->{_perltidyrc} = \$rc;
+ }
+
+ return $TRUE;
+@@ -92,10 +94,16 @@
+
+ # Trap Perl::Tidy errors, just in case it dies
+ my $eval_worked = eval {
++# Perl::Tidy 20120619 no longer accepts a scalar reference for stdio.
++my $handle = IO::String->new( $stderr );
++# Since Perl::Tidy 20120619 modifies $source, we make a copy so
++# we can get a good comparison. Doing an s/// on $source after the
++# fact appears not to work with the previous Perl::Tidy.
++my $source_copy = $source;
+ Perl::Tidy::perltidy(
+-source => \$source,
++source => \$source_copy,
+ destination => \$dest,
+-stderr => \$stderr,
++stderr => $handle,
+ defined $self->{_perltidyrc} ? (perltidyrc =>
$self->{_perltidyrc}) : (),
+);
+1;
diff --git a/perl-Perl-Critic.spec b/perl-Perl-Critic.spec
index d87db68..9f054b0 100644
--- a/perl-Perl-Critic.spec
+++ b/perl-Perl-Critic.spec
@@ -1,11 +1,12 @@
Name: perl-Perl-Critic
Version: 1.117
-Release: 7%{?dist}
+Release: 8%{?dist}
Summary: Critique Perl source code for best-practices
Group: Development/Libraries
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/Perl-Critic/
Source0:
http://search.cpan.org/CPAN/authors/id/T/TH/THALJEF/Perl-Critic-%{version}.tar.gz
+Patch2:Perl-Critic-1.117-tidy.patch
BuildArch: noarch
# Build process
@@ -116,8 +117,12 @@ of Perl code were mixed directly in the test script. That
sucked.
%prep
%setup -q -n Perl-Critic-%{version}
+
+# Fix breakage with Perl::Tidy ≥ 20120619 (CPAN RT#77977)
+%patch2
+
+# Drop Test::Kwalitee tests in RHEL ≥ 7
%if 0%{?rhel} >= 7
-# Drop Test::Kwalitee tests in RHEL >= 7
rm xt/author/95_kwalitee.t
sed -i -e '/^xt\/author\/95_kwalitee.t$/ d' MANIFEST
%endif
@@ -148,6 +153,9 @@ LC_ALL=en_US ./Build %{!?perl_bootstrap:author}test
%{_mandir}/man3/Test::Perl::Critic::Policy.3pm*
%changelog
+* Tue Jul 10 2012 Paul Howarth - 1.117-8
+- fix breakage with Perl::Tidy ≥ 20120619 (CPAN RT#77977)
+
* Tue Jul 10 2012 Petr Pisar - 1.117-7
- Perl 5.16 re-rebuild of bootstrapped packages
@@ -158,7 +166,7 @@ LC_ALL=en_US ./Build %{!?perl_bootstrap:author}test
- conditionalize aspell
* Tue Apr 24 2012 Petr Pisar - 1.117-4
-- Do not use Test::Kwalitee on RHEL >= 7
+- do not use Test::Kwalitee on RHEL ≥ 7
* Tue Feb 28 2012 Paul Howarth - 1.117-3
- spec clean-up
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: UFS / AFFS filesystems
On Tue, Jul 10, 2012 at 10:50:44PM +0800, Ian Chapman wrote: > Hi, > > Have the ufs / affs and other file systems been intentionally > dropped from the F17 kernel, or is that just an oversight? Nothing is mentioned in the changelog, so it would be an oversight. But which precise kernel are you having trouble with, and do you see any error message? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: allow *-static as multilib
Michael Schwendt (mschwe...@gmail.com) said: > Static-only -devel packages with a virtual -static package name are > shipped as multilib already anyway (and -static packages with a virtual > -devel package name probably, too, in case mash takes a look at virtual > package names). It does not (arguably it should.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UFS / AFFS filesystems
On Tue, Jul 10, 2012 at 3:50 PM, Ian Chapman wrote: > Hi, > > Have the ufs / affs and other file systems been intentionally dropped from > the F17 kernel, or is that just an oversight? They're still there but they've been moved to the kernel-modules-extra sub package. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UFS / AFFS filesystems
On Tue, Jul 10, 2012 at 10:59 AM, Richard W.M. Jones wrote: > On Tue, Jul 10, 2012 at 10:50:44PM +0800, Ian Chapman wrote: >> Hi, >> >> Have the ufs / affs and other file systems been intentionally >> dropped from the F17 kernel, or is that just an oversight? > > Nothing is mentioned in the changelog, so it would be an > oversight. Not mentioning it in the changelog does not mean it's an oversight. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UFS / AFFS filesystems
On 07/10/2012 08:39 PM, Josh Boyer wrote: > On Tue, Jul 10, 2012 at 10:59 AM, Richard W.M. Jones > wrote: >> On Tue, Jul 10, 2012 at 10:50:44PM +0800, Ian Chapman wrote: >>> Hi, >>> >>> Have the ufs / affs and other file systems been intentionally >>> dropped from the F17 kernel, or is that just an oversight? >> >> Nothing is mentioned in the changelog, so it would be an >> oversight. > > Not mentioning it in the changelog does not mean it's an oversight. Perhaps but if it is a intentional change, it would be useful to mention the rationale in the changelog. Thats the obvious place that users will look for. Maintainers themselves tend to forget the reason after sometime otherwise. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
UsrMove, /etc/shells, and rpm interpreter requires
I just got the following: grib_api has broken dependencies in the rawhide tree: On x86_64: grib_api-1.9.16-3.fc18.x86_64 requires /usr/bin/ksh On i386: grib_api-1.9.16-3.fc18.i686 requires /usr/bin/ksh Please resolve this as soon as possible. after I decided to stop changing the path of /usr/bin/ksh to /bin/ksh in grib_api since I figured with UsrMove, /usr/bin/ksh should be the proper location. But then I see that ksh still installs in /bin. Before I file a bug against ksh I wanted to make sure that we do indeed want to move to /usr/bin. I see that bash is in /usr/bin, so I guess that's a yes. My other concern though is /etc/shells: # cat /etc/shells /bin/sh /bin/bash /sbin/nologin /bin/tcsh /bin/csh /bin/ksh /bin/zsh Shouldn't that be /usr/ as well. Will it cause problems if it doesn't match with the /etc/passwd entry? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, 10 Jul 2012 15:57:31 +0100, Matthew Garrett wrote: > Saying things like: > > "and arbitrary other people, who get their patch contributions merged, > don't gain any copyright protection on the file or the proper parts of > it," > > is inaccurate and dangerous. It's entirely appropriate to indicate that > it's untrue. I wrote that in the context of files giving credit to *some* people [*], which could (!) be an indication that any _unknown_ changes, which other people may have managed to get included in those files, likely have not been considered substantial enough to qualify for copyright. It could even be that the submitters did not consider the patches substantial enough themselves. That's speculation, I don't like it. But it has been only a question to Petr, because there are lots of files in Audacious that give credit. I've never asked to be credited but have been mentioned nevertheless, and I can only guess what "work" has been recognized. I would not claim rights on tiny patches and bug-fixes another developer could come up with, too, even if a copyright law pedant would claim that I could. [*] Those people believe they do most of the original work to qualify for copyright. > > It boils down to some forms of etiquette, whether and when main project > > developers recognize contributed patches as substantial and automatically > > give proper credits *before* a copyright holder wants to enforce rights. > > It boils down to copyright law. Nothing more. Nothing less. Project > maintainers simply don't get to make that choice on behalf of others. Sure they do. We can go on endlessly. They can reject copying something verbatim, and they may change the code nevertheless in either the same or a very similar way. Coincidentally or because it's an obvious way (and no patented stuf, hey!). Then somebody else would need to decide whether copyright law is applicable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, Jul 10, 2012 at 05:45:15PM +0200, Michael Schwendt wrote: > On Tue, 10 Jul 2012 15:57:31 +0100, Matthew Garrett wrote: > > > Saying things like: > > > > "and arbitrary other people, who get their patch contributions merged, > > don't gain any copyright protection on the file or the proper parts of > > it," > > > > is inaccurate and dangerous. It's entirely appropriate to indicate that > > it's untrue. > > I wrote that in the context of files giving credit to *some* people [*], > which could (!) be an indication that any _unknown_ changes, which other > people may have managed to get included in those files, likely have not > been considered substantial enough to qualify for copyright. Which is a dangerous position to take. Don't say things like that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove, /etc/shells, and rpm interpreter requires
Am 10.07.2012 17:18, schrieb Orion Poplawski: > I just got the following: > > grib_api has broken dependencies in the rawhide tree: > On x86_64: > grib_api-1.9.16-3.fc18.x86_64 requires /usr/bin/ksh > On i386: > grib_api-1.9.16-3.fc18.i686 requires /usr/bin/ksh > Please resolve this as soon as possible. > > after I decided to stop changing the path of /usr/bin/ksh to /bin/ksh in > grib_api since I figured with UsrMove, /usr/bin/ksh should be the proper > location. > > But then I see that ksh still installs in /bin. Before I file a bug against > ksh > I wanted to make sure that we do indeed want to move to /usr/bin. I see that > bash is in /usr/bin, so I guess that's a yes. My other concern though is > /etc/shells: > > # cat /etc/shells > /bin/sh > /bin/bash > /sbin/nologin > /bin/tcsh > /bin/csh > /bin/ksh > /bin/zsh > > Shouldn't that be /usr/ as well. Will it cause problems if it doesn't match > with the /etc/passwd entry? > > yes, /etc/shells might be a problem... I would suggest: install the $shell in /usr/bin/$shell, Provide: /bin/$shell in the spec file and add both paths in /etc/shell or we patch "chsh" and the like? Thoughts? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 838679] perl-Plack: EL-6 build
https://bugzilla.redhat.com/show_bug.cgi?id=838679 --- Comment #4 from Jose Pedro Oliveira --- (In reply to comment #2) > Thanks for the comprehensive summary. Looks like this will be a though one. > About the missing PPC64 packages, this is a pain, but that can be dealt with. This problem appears to be the easiest to fix. > About the test suites, I think it should be acceptable to selectively > disable tests that are failing because of the unmet dependencies. What do > you think ? I'm with Ralf on this one: we should strive to successfully run all the module tests. In order to have perl-Plack in EPEL-6 we need to accomplish the following steps: 1) perl-Crypt-PasswdMD5 needs to be in the EPEL-6 PPC64 repositories Action: import and build perl-Crypt-PasswdMD5 for EPEL-6 with a lower release than the one existing in the RHEL channels. TODO: check if there are modules missing in the PPC64 repos. RHEL 6.x SRPM: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/perl-Crypt-PasswdMD5-1.3-6.el6.src.rpm 2) perl-Devel-StackTrace needs to be updated to a more recent version (at least version 1.23) RHEL 6.x SRPM: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/perl-Devel-StackTrace-1.22-4.el6.src.rpm 3) perl-Test-Simple (Test::More) needs to be updated to a more recent version (ideally from version 0.92 to 0.98) Caveats: The update must be done to the perl package; a patch - perl-update_Test-Simple.patch - needs to added RHEL 6.x SRPM: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/perl-5.10.1-127.el6.src.rpm Although only the first two steps are really mandatory, the third is also highly recommend due to the complexity and security problems of the Plack stack (as Ralf pointed in the previous comment): several modules may need to be updated regularly and some of these updates will need a more recent version of Test::More. I believe the first step can be performed by us. The second and the third steps will need to be performed by Red Hat packagers and most likely in sync with major RHEL releases. /jpo -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On 2012-07-09 10:54, Matej Cepl wrote: > On 06/07/12 22:55, Bill Nottingham wrote: >> Package html401-dtds (orphan) >> comaintained by: gnat > > Does it mean, we won't have HTML 4.01 DTDs packaged in Fedora? No. We're in progress of transfering the ownership of this package from me to gnat, will ping him. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On 07/10/2012 10:29 AM, Ville Skyttä wrote: On 2012-07-09 10:54, Matej Cepl wrote: On 06/07/12 22:55, Bill Nottingham wrote: Package html401-dtds (orphan) comaintained by: gnat Does it mean, we won't have HTML 4.01 DTDs packaged in Fedora? No. We're in progress of transfering the ownership of this package from me to gnat, will ping him. Sorry, had a few busy days and didn't for whatever reason think I had reason to read the retiring packages... I took ownership. -- Nathanael d. Noblet t 403.875.4613 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, 10 Jul 2012 16:52:19 +0100, Matthew Garrett wrote: > On Tue, Jul 10, 2012 at 05:45:15PM +0200, Michael Schwendt wrote: > > On Tue, 10 Jul 2012 15:57:31 +0100, Matthew Garrett wrote: > > > > > Saying things like: > > > > > > "and arbitrary other people, who get their patch contributions merged, > > > don't gain any copyright protection on the file or the proper parts of > > > it," > > > > > > is inaccurate and dangerous. It's entirely appropriate to indicate that > > > it's untrue. > > > > I wrote that in the context of files giving credit to *some* people [*], > > which could (!) be an indication that any _unknown_ changes, which other > > people may have managed to get included in those files, likely have not > > been considered substantial enough to qualify for copyright. > > Which is a dangerous position to take. Don't say things like that. I'd love to take advice from you, but with your overly brief comments you're unconvincing. I don't think copyright law is as simple as to cover it with one-line mails. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 loadavg: 0.54 0.68 0.55 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, Jul 10, 2012 at 11:45 AM, Michael Schwendt wrote: > On Tue, 10 Jul 2012 15:57:31 +0100, Matthew Garrett wrote: > >> Saying things like: >> >> "and arbitrary other people, who get their patch contributions merged, >> don't gain any copyright protection on the file or the proper parts of >> it," >> >> is inaccurate and dangerous. It's entirely appropriate to indicate that >> it's untrue. > > I wrote that in the context of files giving credit to *some* people [*], > which could (!) be an indication that any _unknown_ changes, which other > people may have managed to get included in those files, likely have not > been considered substantial enough to qualify for copyright. Michael, please stop with this. Copyright is automatic under Berne. Whether it "qualifies" is not up to people deciding whether unknown contributors' contributions are "substantial" enough. You're describing an entirely impractical mode of approach. Whatever some group of "recognized contributors" might think, any contributor can bring suit because their code is included. The way to go about it is to recognize it, not constantly try to rationalize a bizarre notion where you get to decide it. Making the determinations you keep bringing up, even in court, is not a very clear legal matter. Just recognize the point -- people who contribute code to a GPL'd project (or any project) automatically have a copyright claim, and you work on that basis, just like any other project contemplating changing their license does. Seth > It could even > be that the submitters did not consider the patches substantial enough > themselves. That's speculation, I don't like it. But it has been only a > question to Petr, because there are lots of files in Audacious that give > credit. I've never asked to be credited but have been mentioned > nevertheless, and I can only guess what "work" has been recognized. > I would not claim rights on tiny patches and bug-fixes another developer > could come up with, too, even if a copyright law pedant would claim that I > could. > > [*] Those people believe they do most of the original work to qualify > for copyright. > >> > It boils down to some forms of etiquette, whether and when main project >> > developers recognize contributed patches as substantial and automatically >> > give proper credits *before* a copyright holder wants to enforce rights. >> >> It boils down to copyright law. Nothing more. Nothing less. Project >> maintainers simply don't get to make that choice on behalf of others. > > Sure they do. We can go on endlessly. They can reject copying something > verbatim, and they may change the code nevertheless in either the same or > a very similar way. Coincidentally or because it's an obvious way (and > no patented stuf, hey!). Then somebody else would need to decide whether > copyright law is applicable. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove, /etc/shells, and rpm interpreter requires
On Tue, Jul 10, 2012 at 06:12:45PM +0200, Harald Hoyer wrote: > Am 10.07.2012 17:18, schrieb Orion Poplawski: > > Shouldn't that be /usr/ as well. Will it cause problems if it doesn't match > > with the /etc/passwd entry? > > > > > > yes, /etc/shells might be a problem... I would suggest: > > install the $shell in /usr/bin/$shell, Provide: /bin/$shell in the spec file > and > add both paths in /etc/shell > > or we patch "chsh" and the like? > Adding both paths to /etc/shell sounds preferable to me. -Toshio pgph2DrC3Xcxh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
Just a note that the following additional packages were orphaned yesterday as part of cleaning up packages owned by people without bugzilla accounts: devilspie dogtail gtkmm-utils k12linux-quick-start-guide kcoloredit kgrab kiconedit koverartist ksig libzip polyester polyester3 python-djblets python-flask python-werkzeug stalonetray tasks -Toshio pgpyfDSkFBhQS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, Jul 10, 2012 at 07:12:01PM +0200, Michael Schwendt wrote: > I'd love to take advice from you, but with your overly brief comments > you're unconvincing. I don't think copyright law is as simple as to cover > it with one-line mails. The only advice I'm offering is to tell you that it's dangerous to tell people things about copyright law when you don't appear to understand copyright law. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, 10 Jul 2012 13:19:09 -0400, Seth Johnson wrote: > Copyright is automatic under Berne. Which only means that you don't need to apply for copyright at any government office. But copyright on _what_? What comprises a "copyright work"? Single words? Single lines of code? Trivial/obvious code fragments some other person who have added at some other point of time? Or more original work only? > people who contribute code to a GPL'd project > (or any project) automatically have a copyright claim, And we still don't know what has been contributed, if at all. And what licensing terms were applied to the file the person contributed to. The project this thread refers to has used different licenses for a long time already. Hey Audacious developers, here's a patch for a missing "return 1;" in libaudcore, and now that you've seen my patch, if you merge that line of code, I claim my rights. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 loadavg: 0.27 0.20 0.15 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On Tue, 2012-07-10 at 10:38 -0700, Toshio Kuratomi wrote: > kcoloredit I think I've missed some mails, but this is a very useful application, is there any alternative? Cheers, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On 07/10/2012 11:05 AM, Michael Schwendt wrote: On Tue, 10 Jul 2012 13:19:09 -0400, Seth Johnson wrote: Copyright is automatic under Berne. Which only means that you don't need to apply for copyright at any government office. But copyright on _what_? What comprises a "copyright work"? Single words? Single lines of code? Trivial/obvious code fragments some other person who have added at some other point of time? Or more original work only? That's a great question. people who contribute code to a GPL'd project (or any project) automatically have a copyright claim, And we still don't know what has been contributed, if at all. And what licensing terms were applied to the file the person contributed to. The project this thread refers to has used different licenses for a long time already. Hey Audacious developers, here's a patch for a missing "return 1;" in libaudcore, and now that you've seen my patch, if you merge that line of code, I claim my rights. Yep, good example. What is the threshold? There is only 1 person who can answer that authoritatively: The judge who ends up presiding over the court case where it's formally asked. Everything else is opinion. Some of it informed: attorneys, some of it educated guessing (devoted groklaw readers), some of it blindingly ignorant. Wherever each member of de...@l.fpo falls on that spectrum, the odds are they shouldn't be giving legal advice because there's only 1 judge and none of us are they. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
Toshio Kuratomi wrote: > Just a note that the following additional packages were orphaned yesterday > as part of cleaning up packages owned by people without bugzilla accounts: > > devilspie I've taken devilspie, but just that it's not removed from fedora since I think it's often useful to Xfce users. Co-Maintainers are welcome and I would also be totally happy if someone steps up and want to take ownership again! Johannes > dogtail > gtkmm-utils > k12linux-quick-start-guide > kcoloredit > kgrab > kiconedit > koverartist > ksig > libzip > polyester > polyester3 > python-djblets > python-flask > python-werkzeug > stalonetray > tasks > > -Toshio > > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, 2012-07-10 at 20:05 +0200, Michael Schwendt wrote: > On Tue, 10 Jul 2012 13:19:09 -0400, Seth Johnson wrote: > > > Copyright is automatic under Berne. > > Which only means that you don't need to apply for copyright at any > government office. > > But copyright on _what_? What comprises a "copyright work"? Single words? > Single lines of code? Trivial/obvious code fragments some other person who > have added at some other point of time? Or more original work only? > > > people who contribute code to a GPL'd project > > (or any project) automatically have a copyright claim, > > And we still don't know what has been contributed, if at all. And what > licensing terms were applied to the file the person contributed to. The > project this thread refers to has used different licenses for a long time > already. > > Hey Audacious developers, here's a patch for a missing "return 1;" in > libaudcore, and now that you've seen my patch, if you merge that line > of code, I claim my rights. Can you stop the useless hyperbole ? The reason why nobody is telling you a hard rule is that there are no hard rules, but often it will be decided on case by case basis. So when re-licensing you have to be paranoid but most importantly do it with the support of a lawyer that knows how to minimize ill effects should someone later decide you did something wrong. That's all was really on the table I think, all people really *can* say is that you cannot assume much about who can claims copyright until you analyze the specific contribution. This is one reason why some people insist in pretending you to surrender any copyright to the project owner when you contribute code. In general if you are doing things in good faith everything will work fine in the end. Just don't try to be casual when addressing the matter as it is not something to underestimate like you seem to be doing. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 ARM GA Release
Is there a build compatible with WM8650 ARM 926 EJ-S or Cortex Nuvoton M0? Regards, Rahul. On Tue, Jun 19, 2012 at 11:06 PM, Paul Whalen wrote: > The Fedora ARM team is pleased to announce that the Fedora 17 GA release > for ARM is now available for download from: > > http://download.fedoraproject.org/pub/fedora-secondary/releases/17/Images/ > > The GA release includes prebuilt images for Versatile Express (QEMU), > Trimslice, > Beagleboard xM, Pandaboard, Kirkwood Plugs, Highbank and iMX based hardware > platforms. > Please visit the announcement page for additional information and links to > specific > hardware images: > > http://fedoraproject.org/wiki/Architectures/ARM/Fedora_17_GA > > We invite you to download the Fedora 17 GA release and provide your valuable > input > to the Fedora ARM team. Please join us on the IRC in #fedora-arm on Freenode > or > send feedback and comments to the ARM mailing list. > > On behalf of the Fedora ARM team, > Paul > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
Toshio Kuratomi wrote: > Just a note that the following additional packages were orphaned yesterday > as part of cleaning up packages owned by people without bugzilla accounts: > kcoloredit > kiconedit > libzip I can help with these. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
Le 10/07/2012 19:38, Toshio Kuratomi a écrit : > python-flask > python-werkzeug > > I actively maintain these two (i pushed Flask 0.8.1 last week, 0.9 will land rawhide soon) as a co-maintainer. As a matter of fact, I would have taken ownership if i had been notified that they were orphaned, but i only got notified that someone else requested (and was automatically granted) ownership. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On Tue, Jul 10, 2012 at 08:30:16PM +0200, Haïkel Guémar wrote: > Le 10/07/2012 19:38, Toshio Kuratomi a écrit : > > python-flask > > python-werkzeug > > > > > > I actively maintain these two (i pushed Flask 0.8.1 last week, 0.9 will > land rawhide soon) as a co-maintainer. > As a matter of fact, I would have taken ownership if i had been > notified that they were orphaned, but i only got notified that someone > else requested (and was automatically granted) ownership. > Sorry about that -- it was easier for me to make these mass changes in the database than through the pkgdb application so no notifications went out. I know that the person who picked up the packages did so because he needed them for things he was working on rather than a special need to own the packages themselves, though -- if you'd like to switch owner/comaintainer roles he'd probably be more than willing. -Toshio pgpuCdsexyg1n.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, 10 Jul 2012 14:20:32 -0400, Simo Sorce wrote: > Can you stop the useless hyperbole ? Sure, can the useless generalization and pedantry stop, too? > The reason why nobody is telling you a hard rule is that there are no > hard rules, but often it will be decided on case by case basis. Hence my initial question on what contribution we talk about? And on possible reasons why there have been no credits anywhere at all. My interest was in the code/patch contribution only, as the translation work has been given credit for. > So when re-licensing you have to be paranoid but most importantly do it > with the support of a lawyer that knows how to minimize ill effects > should someone later decide you did something wrong. Oh, legal advice. How many small and losely organized FLOSS projects with no commercial backing consult a lawyer when they relicence or merge code from other projects? > That's all was really on the table I think, all people really *can* say > is that you cannot assume much about who can claims copyright until you > analyze the specific contribution. This is one reason why some people > insist in pretending you to surrender any copyright to the project owner > when you contribute code. Yes, please, can we analyze specific contributions? I've pointed out more than once that many files have been replaced or deleted, which increases the chance that old(er) contributions and inherited code sections are not left anymore. > In general if you are doing things in good faith everything will work > fine in the end. Just don't try to be casual when addressing the matter > as it is not something to underestimate like you seem to be doing. Not clear what you think I underestimate. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 loadavg: 0.09 0.24 0.38 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
Le 10/07/2012 20:42, Toshio Kuratomi a écrit : > > Sorry about that -- it was easier for me to make these mass changes in the > database than through the pkgdb application so no notifications went out. > I know that the person who picked up the packages did so because he needed > them for things he was working on rather than a special need to own the > packages themselves, though -- if you'd like to switch owner/comaintainer > roles he'd probably be more than willing. > > -Toshio > I'd rather have new co-maintainers sending an email or opening tickets before being granted the commit bit. That avoids potential misunderstandings or conflicting changes. :] I'm more worried about werkzeug/flask - which i also use for some admin web apps- consistent packaging than ownership. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On Tue, 10 Jul 2012 20:30:16 +0200, Haïkel Guémar wrote: > Le 10/07/2012 19:38, Toshio Kuratomi a écrit : > > python-flask > > python-werkzeug > > > > > > I actively maintain these two (i pushed Flask 0.8.1 last week, 0.9 will > land rawhide soon) as a co-maintainer. > As a matter of fact, I would have taken ownership if i had been > notified that they were orphaned, but i only got notified that someone > else requested (and was automatically granted) ownership. Could you please respond to http://bugz.fedoraproject.org/python-feedparser in particular the aging NEEDINFO query in #787401 that addresses you? -- Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 loadavg: 0.62 0.27 0.31 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
> On Tue, 10 Jul 2012 16:52:19 +0100, Matthew Garrett wrote: > >> On Tue, Jul 10, 2012 at 05:45:15PM +0200, Michael Schwendt wrote: >> > On Tue, 10 Jul 2012 15:57:31 +0100, Matthew Garrett wrote: >> > I wrote that in the context of files giving credit to *some* people >> [*], >> > which could (!) be an indication that any _unknown_ changes, which >> other >> > people may have managed to get included in those files, likely have >> not >> > been considered substantial enough to qualify for copyright. >> >> Which is a dangerous position to take. Don't say things like that. > > I'd love to take advice from you, but with your overly brief comments > you're unconvincing. I don't think copyright law is as simple as to cover > it with one-line mails. Please consider that in the Oracle vs Google case, Oracle ended up with 9-line copying (plus a few test files), and the judge decided that *as* *a* *matter* *of* *law* copyright infringement had occurred for those 9 lines. http://www.groklaw.net/article.php?story=20120510205659643#1119 That's what a very smart judge decided in a huge trial with some of the countries top lawyers involved. I don't have any clear idea what is not substantial enough to qualify for copyright, but this very simple code did https://news.ycombinator.com/item?id=3940683 -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, Jul 10, 2012 at 3:33 PM, Nicolas Mailhot wrote: > Please consider that in the Oracle vs Google case, Oracle ended up with > 9-line copying (plus a few test files), and the judge decided that *as* > *a* *matter* *of* *law* copyright infringement had occurred for those 9 > lines. Yes. And also told Oracle that it was very limited what they could claim as damage caused by the copyright infringement over those 9 lines. Yes, those 9 lines belong to you my precious butterfly. No, they are not significant and this is all a waste of time. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
Le 10/07/2012 21:07, Michael Schwendt a écrit : > > Could you please respond to > http://bugz.fedoraproject.org/python-feedparser > in particular the aging NEEDINFO query in #787401 that addresses you? > I'm looking that issue right now. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: intel ipw2100/ipw2200 firmware must be removed
Hi. On Tue, 10 Jul 2012 17:52:28 +0530, Rahul Sundaram wrote > Do we have any such firmware at all? Let's stick to practical issues. Wei don't, as far as I am aware. But with Intel actually preparing to ship Xeon Phi hardware we might sooner than later. -- "The creatures looked from pig to man, and from man to pig, and from pig to man again: but it was impossible to say which was which." -- George Orwell, "Animal Farm" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, Jul 10, 2012 at 3:48 PM, Martin Langhoff wrote: > Yes. And also told Oracle that it was very limited what they could > claim as damage caused by the copyright infringement over those 9 > lines. Very limited in the context of billion dollar lawsuits. Statutory infringement for commercial use makes any infringement a potentially non-trivial at the level of mere mortals. Besides, the damages are generally irrelevant the FUD and disruption are the real costs. The only litigation that ends up in front of a judge are where one or both parties is either crazy or a fool. Everyone else settles. But this is a silly discussion. There is substantial jurisdictional differences on the bar of copyrightability, and because there are basically no useful bright lines the details are basically not worth discussing. The point is that being cautious and conservative is a very good policy and about the only one which can be sanely advocated. If someone's contributions are really insignificant then it's no big deal to replace them if they're being unfriendly and are unwilling to go along with a re-licensing. It may be a bit of a pain, but it's much less of a pain than.. this discussion not to mention the pain of a potential legal dispute. And no, re-licensing a many-authored project isn't simply fun or easy. This is also a reason why projects should practice good hygiene upfront, and checking up on this— and propagating best practices— is one of the services a packager can provide to their upstreams. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, Jul 10, 2012 at 03:48:52PM -0400, Martin Langhoff wrote: > On Tue, Jul 10, 2012 at 3:33 PM, Nicolas Mailhot > wrote: > > Please consider that in the Oracle vs Google case, Oracle ended up with > > 9-line copying (plus a few test files), and the judge decided that *as* > > *a* *matter* *of* *law* copyright infringement had occurred for those 9 > > lines. > > Yes. And also told Oracle that it was very limited what they could > claim as damage caused by the copyright infringement over those 9 > lines. > > Yes, those 9 lines belong to you my precious butterfly. No, they are > not significant and this is all a waste of time. But Google are not permitted to redistribute that code. If a work is relicensed without the assent of all copyright holders then the work is undistributable, no matter how small any damages might be. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
On Tue, 10 Jul 2012 21:33:26 +0200, Nicolas Mailhot wrote: > Please consider that in the Oracle vs Google case, Oracle ended up with > 9-line copying (plus a few test files), and the judge decided that *as* > *a* *matter* *of* *law* copyright infringement had occurred for those 9 > lines. > > http://www.groklaw.net/article.php?story=20120510205659643#1119 > > That's what a very smart judge decided in a huge trial with some of the > countries top lawyers involved. > > I don't have any clear idea what is not substantial enough to qualify for > copyright, but this very simple code did > https://news.ycombinator.com/item?id=3940683 Do you think a few more verdicts like that will influence small FLOSS projects? In that they will not apply proposed fixes "faster, faster, faster", http://www.i-programmer.info/news/193-android/4224-oracle-v-google-judge-is-a-programmer.html but will spend a bit more time on creating the fixes/code changes themselves? -- Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 loadavg: 0.33 0.26 0.41 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
On Ter, 2012-07-10 at 02:11 +0100, Sérgio Basto wrote: > On Seg, 2012-07-09 at 05:54 +0100, Sérgio Basto wrote: > > On Sex, 2012-07-06 at 16:55 -0400, Bill Nottingham wrote: > > > Removing: raptor > > > flickcurl requires libraptor.so.1 > > > flickcurl requires raptor-devel = 1.4.21-11.fc17 > > > flickcurl-devel requires raptor-devel = 1.4.21-11.fc17 > > > flickcurl-devel requires pkgconfig(raptor) = 1.4.21 > > > liblrdf-devel requires raptor-devel = 1.4.21-11.fc17 > > > librawstudio requires libraptor.so.1 > > > rawstudio requires libraptor.so.1 > > > tracker requires raptor-devel = 1.4.21-11.fc17 > > > > from > > http://lists.fedoraproject.org/pipermail/devel/2012-June/168262.html > > "So can we get flickcurl and (lib)rawstudio ported to raptor2? I think > > raptor 1 needs to be retired sooner or later." > > I open a bug > https://bugzilla.redhat.com/show_bug.cgi?id=838709 > > to compile flickcurl against raptor2, I test in my local machine with > mock and flickcurl and rawstudio compiles without problems with > raptor2 ... flickcurl has been updated to 1.22 and build in rawhide with raptor2-devel. So librawstudio and rawstudio should be rebuild , anyone do this ? please BTW also darktable depend on flickcurl library ... Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
> On Tue, Jul 10, 2012 at 3:33 PM, Nicolas Mailhot > wrote: >> Please consider that in the Oracle vs Google case, Oracle ended up with >> 9-line copying (plus a few test files), and the judge decided that *as* >> *a* *matter* *of* *law* copyright infringement had occurred for those 9 >> lines. > > Yes. And also told Oracle that it was very limited what they could > claim as damage caused by the copyright infringement over those 9 > lines. He told them they could claim 15$ for those IIRC. That's pocket change for Oracle and Google but not for your average free software project. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing change: Audacious - GPLv3 --> BSD
> On Tue, 10 Jul 2012 21:33:26 +0200, Nicolas Mailhot wrote: > >> Please consider that in the Oracle vs Google case, Oracle ended up with >> 9-line copying (plus a few test files), and the judge decided that *as* >> *a* *matter* *of* *law* copyright infringement had occurred for those 9 >> lines. >> >> http://www.groklaw.net/article.php?story=20120510205659643#1119 >> >> That's what a very smart judge decided in a huge trial with some of the >> countries top lawyers involved. >> >> I don't have any clear idea what is not substantial enough to qualify >> for >> copyright, but this very simple code did >> https://news.ycombinator.com/item?id=3940683 > > Do you think a few more verdicts like that will influence small FLOSS > projects? In that they will not apply proposed fixes "faster, faster, > faster", You complained no one here was a lawyer and any residual changes would be deemed not qualifying under copyright law. I posted a reference to a very recent judgement where a very good lawyer tried to argue the same for nine very simple code lines over a code corpus that dwarfs audacious (not qualifying seems to be written de minimis in american lawyer speek) and a very good judge refused the argument. If that's not good enough for you as authoritative reference I don't know what could be. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
