hi, On Sat, Oct 19, 2013 at 8:44 PM, Hannes Magnusson <[email protected]> wrote:
> Since the inception of github, more and more projects have these files > as .md, and I used to see a good chunk of projects that used .txt many > years ago. > > There no legal or any imaginable requirement that prohibits this. Its > simply a convention. File extensions make things easy for the user and > can alter the rendering of the file, so its perfectly fine to name it > .md or .txt. Yes, custom extensions are just fine. As I said earlier, feel free to provide a patch, PR or add it if we don't add custom extension support soon enough. >> Another point is that you keep repeating "windows" while the relation to >> any binary distribution was clearly stated. The point just has come, >> where the need for clear license information is collapsed for multiple > > Well, we currently only support source distribution, and Windows > binaries. We don't provide other binaries at the moment. If my > mentioning of Windows was of any shame to you, then I apologize. It > was only meant to note that the due to the inclusion of the Windows > build system some breaking changes have been made. The extension is broken if the versions do not match, they should not be released with broken version numbers. Fix it and repackage sound like the right way. >> parties. It's needed for binary distributions under windows and linux. >> Yes, we can parse package.xml, the google search and even files named >> schnitzel, but is that the goal? And that'll never work properly anyway. >> And whil a PECL package contains source only, there are reasons as well >> to put a separate license file in there, for more here for instance > > > If you don't want to do filename matching, wouldn't then adding a > role="license" be a better choice? > Then I can do whatever schnitzel I want as the author, even include > two or more licensing options (or, requirements, as is the case when > extensions bundle other things). That's something to valid with pear. >> more already has a license file. In fact, many of the really active >> projects already had the lic file included by themselves before this >> change. So who needs the mommy? > > Excellent! And they all (RFC 2119) SHOULD. > But just because they should, doesn't mean we need to error out if its > not there. Should is like must in this context. >> Concerns about the efforts of putting one file into the source code, >> aren't that blanks? That is just a one time action except some project > > Sure. But unfortunately we have a problem with one of the main > extensions here, namely oci8. > This is a huge issue for legal reasons for them. > > And what about the extensions that bundle external library, for > example pecl/zip, which both Pierre and Remi are the authors of.. How > are you including the license of libzip? We do it. See https://github.com/pierrejoye/php_zip/ LICENSE It the license of the extension itself, and we include other flicense files for the bundle libraries. >> In any case, I really hold what is done for right. While it's left to >> everyones personal judgement. In my opinion that has something to do >> with respecting your own work. It has to do with playing in team with >> downstream distributors and respecting their work, as well as everyones >> else. And it has to do with what OSS spirit is. > And what about those who need to distribute multiple files? > Or those who legally cannot add it? No problem, see zip. And if an extension has a license issue, so badly that they can't define it, then we really have other issues with this extension than the LICENSE(.*) file. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
