RE: [PECL-DEV] Re: [Proposal] id3v1

Wez Furlong wrote: > > While we can link to LGPL in PECL, and we can also bundle LGPL in our > repos, it isn't a good idea, as any fixes that we make to that > automatically promote > our lovely PHP licensed code into the realms of GPL. RMS could argue that > even hacking the configure script to fit our build system is classed as > modifying the code. Unless I'm mistaken, the LGPL isn't that restrictive. You can modify and distribute LGPL code as long as you make known that it's been modified, what the modifications were and when they were made. I don't think that just because you distribute it with modifications that your code that links to the library becomes GPL at all, or that you have to change licenses on your app. Isn't that the whole point of the LGPL? That you can use it with your apps without changing your license as long as the library itself remains under the LGPL? Of course, I could be utterly wrong on that, as I haven't used an LGPL library before for anything I've actually distributed, so I've never had to worry about it before... > > Quite frankly, it's a pain in the ass, so I would be -100 on having the > library bundled with it unless it has a sensible BSD style license. Even > when the library has a safe license, bundling is a pain in the neck, as we > then need to keep up to date with the latest versions. > id3lib development is kind of slow (the last release was something like a year ago), but yeah, we've already kind of seen the craziness that goes on around the various libs already bundled with PHP and those that were bundled in the past. License issues aside, a pain in the arse is still a pain in the arse, no question there. > From what I saw of Stephans code, there really is no need for a library > anyway, let alone one with 40 or so functions--what on earth are they all > for? > :) There's something like 20 or so for general use. Most people would probably use those (set_year(), get_track(), that sort of thing.) There's another set of general use functions that are for MP3 info that have nothing to do with ID3 tags per se but are useful for MP3s and MPEG files in general (frame_size(), mpeg_version(), channel_mode(), etc.). And then there's a handful of functions that let you really get into the deep portions of ID3 tags, right down the field and frame levels. It's kind of overkill, but I like to be thorough. Some of the functions could perhaps just be clumped together (like the MPEG/MP3 info functions could really just be sucked into one function that returns an array of the information or something) and the frame/field functions would only really be used for the rather esoteric and exotic frames ID3 has. But the functionality is already there, so whatever. It's not like they have to be used or anything. I would imagine most people would only really use the first couple of functions for reading and writing tags, and the informational functions if they're doing any sort of cataloging or displaying general MP3 info. > > So, the summary is: pain the in the ass and neck and will GPL your soul. > ;-) > > --Wez. > I'm not entirely clear on the LGPL issues, but I'll concede to the pain-in-the-ass factor. I was probably sort of lucid when I threw that suggestion out, it was a long day at work and I was hopped up on jugs of coffee due to lack of sleep. I was typing faster than I was thinking. I mean, I've already witnessed the Great libxml Bundling War of 2003, why the hell would I even think of bundling...? Anyways, all of that aside, the code is available. Whether it's used or not, it doesn't really matter to me. I use it for a few pet projects at work, which was all it was really intended to do, so I'm happy with that. J