Summary: | new ebuild: media-sound/mac (linux ported version of monkey's audio converter) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Kuther <gimpel> |
Component: | New packages | Assignee: | Gentoo Sound Team <sound> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | ajd20000, bertrand, bugs_gentoo_org.Tim_OKelly, burigufutsushide, chiguire, claudiovalente, dominique.c.michel, felipe_spokwa, gimpel, gpanzera, ilvez, kavol, magnade, mail, manphiz, mehmet, mp, nitro, orzel, ps, seemant, Stefano, tomaszg, tove, trustees, world.root, yngwin |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://sourceforge.net/projects/mac-port/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
mac-3.99.4.3.ebuild
media-sound/mac-3.99.4.4.ebuild media-libs/mac/mac-3.99.4.4.ebuild mac-pointercasting.patch mac-precision.patch media-libs/mac-3.99.4.4-r1 media-libs/mac-3.99.4.5.ebuild |
Description
Thomas Kuther
2005-05-30 03:21:02 UTC
Created attachment 60176 [details]
mac-3.99.4.3.ebuild
without a clear license we won't support it, see bug 52882 *** Bug 96621 has been marked as a duplicate of this bug. *** *** Bug 99280 has been marked as a duplicate of this bug. *** *** Bug 109112 has been marked as a duplicate of this bug. *** *** Bug 109115 has been marked as a duplicate of this bug. *** #109115 is not a duplicate of this bug, it depends on this package but it's a different package, it's a xmms pluggin, this is just a lib and some utilities. *** Bug 109248 has been marked as a duplicate of this bug. *** Created attachment 70716 [details]
media-sound/mac-3.99.4.4.ebuild
I was able to build mac on a amd64 box and also on my powerbook (ppc) laptop. I have made a few changes to the ebuild, using versionator to translate the author's funky versioning system to a numerical one. For example, mac-3.99-u4-b4 is 3.99.4.2 Second, you probably should make nasm as a dependence of only x86 systems. I have ammended the ebuild to reflect that dependecy for x86. Thanks, Felipe *** Bug 111560 has been marked as a duplicate of this bug. *** *** Bug 115476 has been marked as a duplicate of this bug. *** reopening for Magnade's fixes Created attachment 75468 [details]
media-libs/mac/mac-3.99.4.4.ebuild
updated ebuild bit cleaner than what was here
also has 2 patchs needed for amd64 and gcc4
i also suggest putting it in media-libs instead as flac is there
and does same as mac does
Created attachment 75469 [details, diff]
mac-pointercasting.patch
Created attachment 75470 [details, diff]
mac-precision.patch
Bret, while I really appreciate your effort, we simply cannot put this into portage without a clear and valid license. LICENSE="unknown" is not one of them. See Bug 52882 for details. There's no point in reopening this bug unless you are able to get into contact with the *original* author and make him re-license the code. If people use your ebuilds attached to this bug, it's all fine, but the ebuild can't get into the tree unless the above-mentioned issues are solved. i put in unknown in part to catch the dev attention that would be commiting it as it would require prob making a 'monkey' licence file to put in licences directory i had forgotten to comment as such there is a htm file in the src dir that says what the licence is for readablity ditching the html formatting might be wanted as for relicencing thats not my job nor is it needed for gentoo if you dont believe me have a look in /usr/portage/licenses/ and read over 1 or 3 of hte 500 some licences there (In reply to comment #13) > reopening for Magnade's fixes Why? I don't think that we can take this package into consideration, as long as there's no valid license. Grabbing some proprietary source code, applying some minor changes and releasing it under LGPL is strictly illegal. i dont think that is gentoo's problem and after looking over gentoo.org i also dont see any policy stating that it should be or that licencing should even be considered when creating/commiting a ebuild, as all ebuilds are is an install script the end user is the one that desides if the licence is evil or not and to use it or not (In reply to comment #20) > i dont think that is gentoo's problem and after looking over gentoo.org > i also dont see any policy stating that it should be > or that licencing should even be considered when creating/commiting > a ebuild Huh? You are not entirely serious, are you? Valid license is MANDATORY for every single ebuild in portage. > all ebuilds are is an install script > the end user is the one that desides if the licence is evil or not > and to use it or not Which license? There's no license, someone has forked this and hosted the forked project on SF under a fake LGPL license, without author's consent (see Bug 52882, comment #33 or COPYING in the tarball). This is apparently illegal. Or are you suggesting that committing an install script that will grab e.g. MS Windows from Gentoo mirrors and install is legal?! To quote the original license: <snip> 1. The use of any of the Monkey's Audio source code or any component thereof from another program requires express written permission from the author of Monkey's Audio. 2. The use of Monkey's Audio or the Monkey's Audio source code for any commercial purposes including, but not limited to, implementation in shareware packages is strictly prohibited without first obtaining written permission from the author. </snip> The above license sucks big time, and I don't see any place for such proprietary thing in portage while there are perfectly open source alternatives like media-libs/flac, licensed under GPL-2/LGPL-2. > Huh? You are not entirely serious, are you? Valid license is MANDATORY for > every single ebuild in portage. yes i am serious and there is a licence it could very well be marked monkey and use the orignal licence > The above license sucks big time, and I don't see any place for such > proprietary thing in portage while there are perfectly open source alternatives > like media-libs/flac, licensed under GPL-2/LGPL-2. yes well some people dont have the luxury of having or dealing with just opensource codecs with nice licenses if this is such a problem why not set fetch restriction and point the user to the issue and let them deside twice over that they want to install it (In reply to comment #22) > yes i am serious and there is a licence it could very well be marked monkey > and use the orignal licence This is wrong for two reasons: First you'd need to ask everyone who committed code to the illegally LGPL'ed version to accept a license change and give the original author of the codec all rights on it. Second, there simply is nothing I'd call a license; Instead there're two weird formulated, unclear if not contradictory texts, one inside of the "original" tarball, one on the authors website. As a bonus this guy doesn't answer emails. I don't see anything happen unless someone achieves to contact the codec author and clears everything up and don't see why I shouldn't close it again. If you disagree, please don't reopen, but start a discussion on the gentoo-dev mailing list, to hear what other devs say. *** Bug 117382 has been marked as a duplicate of this bug. *** *** Bug 123439 has been marked as a duplicate of this bug. *** Created attachment 83225 [details]
media-libs/mac-3.99.4.4-r1
correct the SRC_URI to be able to use sourceforge mirrors.
I fail to see the point of updating this ebuild to use an illegal tarball... reguardless of what its legal status of a tarball some people use it for whatever reasons and those people also choose to update the ebuild to make sure it works for those folks that have to put up with this annoying format I'd like to request that the gentoo devs take another look at this package and consider it for inclusion. I know that historically Monkey's Audio has had restrictive licensing, which is why this ebuild was marked as wontfix. However, it appears that the license has been updated and made significantly less restrictive, to the point that inclusion in should be permissible. The license can be found here: http://www.monkeysaudio.com/license.html Of note: Source code is now available, which "can be freely used to add APE format playback, encoding, or tagging support to any product, free or commercial." -and- "Monkey's Audio source can be included in GPL and open-source software." There are some caveats in there as well, however none of them would seem to preclude adding this ebuild to portage. Please review and let me know if this is still a problem. Thanks. Support for the last comment. As it seems that the license has now been made compatible with inclusion in the portage tree, please do so. This damn .ape format is all over the place and it really gets you crazy even just to understand what kind of tools you need to read it; by adding the package, at least the average user could find something with emerge -s. Has onyone aside from Vittorio read last comment? Or should I post a separate bug since this one is marked as resolved/wontfix? The legality of a license that says "this can be used with gpl" is on itself something I wouldn't bet on. Also, this does not really mean it satisfy GPL compatibility at all. If you _really_ want this in portage, please go asking FSF support for the compatibility of that change. Note that the license is _not_ GPL at this point anyway, and that the SF.net project still results in a *fake* LGPL license. Has anybody checked with the Free Software Foundation if that license is indeed compatible with a derived work begin marked GPL/LGPL? Regardless, the license in the latest release from the sourceforge project has been changed to refer directly to the latest License.html from the monkeyaudio site (and the author gives an apology for the problems caused by faking LGPL) -- doesn't this resolve the issue altogether? There is much other software in portage that does not have an open license, e.g. VMWare. i created a 'media-libs/mac' directory in my overlay, with the 3.99.4.4-r1 ebuild, and also copied (in files/) both patch. The compilation fails with : * Applying mac-precision.patch ... * Failed Patch: mac-precision.patch ! * ( /usr/portage-overlay/media-libs/mac/files/mac-precision.patch ) and mac-3.99.4.4-r1/temp/mac-precision.patch-16645.out contains: ***** mac-precision.patch ***** =============================== PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < /usr/portage-overlay/media-libs/mac/files/mac-precision.patch =============================== can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- mac-3.99-u4-b4/src/MACLib/APESimple.cpp.old i created a 'media-libs/mac' directory in my overlay, with the 3.99.4.4-r1 ebuild, and also copied (in files/) both patch. The compilation fails with : * Applying mac-precision.patch ... * Failed Patch: mac-precision.patch ! * ( /usr/portage-overlay/media-libs/mac/files/mac-precision.patch ) and mac-3.99.4.4-r1/temp/mac-precision.patch-16645.out contains: ***** mac-precision.patch ***** =============================== PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < /usr/portage-overlay/media-libs/mac/files/mac-precision.patch =============================== can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- mac-3.99-u4-b4/src/MACLib/APESimple.cpp.old· 2005-11-28 11:10:22.000000000 -0800 |+++ mac-3.99-u4-b4/src/MACLib/APESimple.cpp· 2005-11-28 11:12:04.000000000 -0800 -------------------------- No file to patch. Skipping patch. 3 out of 3 hunks ignored can't find file to patch at input line 32 Perhaps you used the wrong -p or --strip option? oh, ok, my fault, there was a mismatch with patch file names. (tgz are better!) the ebuild works fine here. thx :) My 2 cents contribution. Many red-hat mirrors have differents versions of this ape codec in the contrib or the non-free directory: http://www.filewatcher.com/_/?q=APE-*.rpm Get me a digitally signed statement of one of FSF lawyers saying that this is safe to link MAC into GPL stuff, and it might be done. Up to that point, mac-port is just one more legal trouble I don't want to face in my life. *** Bug 155191 has been marked as a duplicate of this bug. *** *** Bug 156890 has been marked as a duplicate of this bug. *** eh, sorry for dupes, this bugzilla has horrible search behaviour :-((( (and I was even googling for some time if someone did not make the ebuilds before me ...) so, I have to ask: DID THE GENTOO DEVS MENTIONED THE MAC LICENSE CHANGE?!? see http://www.monkeysaudio.com/license.html if you still insist that you cannot include this, then please remove vmware, nvidia stuff and any other ebuilds that do not get well with GPL ... or better, leave Gentoo development team and go to support the Debian 'everything-pure' zealots! (In reply to comment #40) Instead of this pointless ranting, you time would be better spent trying to make upstream to re-license the thing under something else than this stupid homebrew license. Until then, tough luck. (In reply to comment #41) > (In reply to comment #40) > > Instead of this pointless ranting, you time would be better spent trying to > make upstream to re-license the thing under something else than this stupid > homebrew license. Until then, tough luck. I do not understand where this opinion that you have the one and only universal right comes from ... there is a problem and there are two solutions: 1) make the upstream change license 2) make Gentoo devs accept the license trying 1) is "time spent good" (because the license is "stupid") trying 2) is "pointless ranting" (because the "předposran (In reply to comment #41) > (In reply to comment #40) > > Instead of this pointless ranting, you time would be better spent trying to > make upstream to re-license the thing under something else than this stupid > homebrew license. Until then, tough luck. I do not understand where this opinion that you have the one and only universal right comes from ... there is a problem and there are two solutions: 1) make the upstream change license 2) make Gentoo devs accept the license trying 1) is "time spent good" (because the license is "stupid") trying 2) is "pointless ranting" (because the "předposraná"[*] Gentoo license policy is above the interests of the users, nevertheless that it is violated every here and there) what gives you the moral right to decide that 1) is good and 2) is bad? to decide that if there are two sides of which one has to step back, than it must be the second side and not you? from my point of view, solution 2) would be much better - because I do not see any problem with the license, if the authors decided that we may use it, why the heck we could not use it? I do not see any legal problem with it - if you do, then please quote the sources and I will stop "ranting" or, you may say that there is only a few Gentoo developers and you do not have the capacity to maintain another ebuilds - I will be sad about it but I will accept it ... but do not hide such reasons behind the impression that including this is unacceptable for the Gentoo policy thanks for your attention and understanding[**] :-) [*] special Czech term for Jakub :-) - means something like "doing much more than it is asked to do just to be sure that my ass will be safe", the worst form of "servility" to the "higher powers" [**] ok, to say that explicitly: I appreciate much the work of all the people involved in Gentoo, but this does not mean that I cannot disagree in particular things - and if I present my opinion here, it is because I want the problem to be solved, not to swear at somebody ... I can live with the fact that Jakub or Diego have different opinion than me, but it is impossible for me to accept that their opinion is better than any other else, unless they will provide some sources supporting it - probably then I will change my opinion, but until that time I have to express my disagreement, and please excuse me if I will do it in some impolite way - I like things straight (In reply to comment #42) Here's an idea... take the ebuild, stick it into your overlay and move on to something else. The license in broken in multiple regards and not acceptable for Gentoo. Been discussed multiple times in multiple places, won't repeat it here yet again. Read this bug, read the other bugs, read the multiple threads on gentoo-dev mailing list. > because I do not see > any problem with the license, if the authors decided that we may use it, why > the heck we could not use it? So go and use it; nothing prevents you from doing it. We won't distribute it until there's a sane license free of nonsensical, legally ambiguous and GPL-incompatible junk - simply because it's no way worth the trouble. Thanks, bye. (In reply to comment #43) > (In reply to comment #42) > > Here's an idea... take the ebuild, stick it into your overlay that is exactly what I have done now I have an idea too - stop telling people what they should do > The license in broken in multiple regards and not acceptable > for Gentoo. Been discussed multiple times in multiple places, won't repeat it > here yet again. no need to repeat, a simple link would be enough - not one at hand? then I do not trust you > Read this bug, anything before comment 29 - license change - is irrelevant, and after comment 29 there is only Diego's asking for FSF statement, which does not explain what is wrong in any way > read the other bugs, if you refer to bug 52882 it is the same - no new information after the change, just circular reference to this bug > read the multiple threads > on gentoo-dev mailing list. ok, tried ... http://marc.theaimsgroup.com/?l=gentoo-dev&w=2&r=1&s=Monkey&q=b the most recent thread about it begins 2005-12-25 2:11:53 - before the change, so, once again, totally irrelevant any other suggestions? > We won't distribute it until there's a sane license free of nonsensical, > legally ambiguous and GPL-incompatible junk good rhetorical exercise ... and now, what exactly does not make sense? here: http://www.monkeysaudio.com/smf/index.php?topic=2263.0 are some concerns about the second paragraph: "2. Monkey's Audio source can be included in GPL and open-source software, although Monkey's Audio itself will not be subjected to external licensing requirements or other viral source restrictions." - however this does not prevent redistribution in any way, nor taking the sources as a basis for another software, it just prevents the new software being licensed GPL (at least the parts that include the MAC sources) and, besides, ebuild is just an install script ... but it was already discussed within the abovementioned mailinglist thread btw, talking about what makes sense ... I do not think that marking plugins requests DEPENDING on this bug DUPLICATES of this makes sense We really need the ability to lock bugs... :( Go search the MA forums for license-related issues and questions. All the threads are completely ignored by the developers. So, once again - we are NOT including this under the current license, and you can argue this until your face is all blue, won't change anything. It prevents redistribution due to clause #6. End of discussion. The problem is, and let me put it in Czech for you, Ty do toho cumis jako Slovak do hodin. It won't be added, the opinion won't be changed. This bug will get you no where. Created attachment 103664 [details]
media-libs/mac-3.99.4.5.ebuild
Created a patch for mac3.99-u4-b5.
The patches against 3.9.4.4 failed so I omitted them.
This works for me on an x86.
Ebuild added to berkano overlay, for whomever wants to risk the license. http://forums.gentoo.org/viewtopic-t-508174.html I was just reading the license page... I don't see any reason why we couldn't copy the license from there a file in portage, such as licenses/mac and use LICENSE="mac" in the ebuild. file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/licenses/mac?rev=1.1&view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/licenses/mac?rev=1.1&content-type=text/plain file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-sound/mac/mac-3.99.4.5.ebuild?rev=1.1&view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-sound/mac/mac-3.99.4.5.ebuild?rev=1.1&content-type=text/plain http://sources.gentoo.org/viewcvs.py/gentoo-x86/licenses/mac?rev=1.1&view=markup The license does not allow redistribution of the source. So we can't mirror it. This was already said in comment 48. what about having ebuild pointing only to 3-rd party mirror? The original mac-port in sf.net claimed it's LGPL. This is something different, and from different location. It's using the SDK and come's with the SDK license. It's not used in any GPL or LGPL project. COPYING, See src/License.html. I faked the LGPL license in order to make it hosted at SourceForge, I am very sorry for this to other Free Software developers. We all hope that the original author will change the license to some standard open source licenses. src/License.html is same as licenses/mac and same as http://www.monkeysaudio.com/license.html No *GPL anywhere. + 06 Oct 2009; Samuli Suominen <ssuominen@gentoo.org> mac-3.99.4.5.ebuild: + RESTRICT="mirror" because the license doesn't explicitely grant permission + to redistribute, only to use. |