I think all the individual files also have a license statement.

@brandonkelly In order to relicense a project, you will need the consent of all authors. I am the original author of PEL and while I picked the GPL way back in the day, I'm actually okay with changing the license to a more permissive license now.

Maybe you should even change the license to the MIT license? The LGPL is sometimes sees as too restrictive, even if it allows proprietary programs to link to the LGPL code.

You should look at the the commits (not just git blame) to find the people who has a stake in this and contact them. Have them give their okay on this pull request and you should be good to go.

@mgeisler Thanks for chipping in. I agree with going for the MIT license. @brandonkelly when all committers comment on this issue, and the license is changed everywhere, we will change it. Thanks for doing this.

Many of the recent refactorings were committed by me. I'd also agree to a license change to LGPG or even better to MIT.

@brandonkelly, will you contact all the people which were involved? Also people who offered test-cases or did some small fixes must be contacted.

@brandonkelly Are you moving forward with this, or should we close the pull request for the time being?

Sorry folks - got sidetracked by a new baby boy that came a couple weeks earlier than expected, and have been on parental leave. I agree MIT would be way better - I didn't want to get too greedy with my initial request :) I'll try to get in touch with the other committers!

We have the following in favor of either using LGPL or MIT (each preferring MIT):

• @mgeisler
• @lsolesen
• @weberhofer
• myself

And we are waiting to hear from:

• @darkain
• @AlexMiroshnikov
• @robinlehrmann

@brandonkelly I like open source software and I respect its authors' decisions, so I have no any objections against MIT.

Yes, please do it!

Ok, that leaves @robinlehrmann, who as far as I can tell from https://github.com/lsolesen/pel/commits?author=robinlehrmann hasn't really touched the core code, just modified composer.json to add PSR-4 autoloading support. I'd say we've reached a consensus on MIT. Agree, @lsolesen / @mgeisler ?

@brandonkelly Thanks for leading this! PEL was one of my first open source projects and I'm happy to see it becoming active again :-)

As for the license change, you should technically remove code contributed by people you cannot reach. Getting a majority or consensus is not enough.

As I understand it, changes that are not "original" are not covered by copyright. I count merges here, so we can leave them behind. The 377a9f1 and 939864c commits are so small that I will say that they're "unoriginal" (sorry @robinlehrmann).

Most of the test images were contributed by others under the GPL. Maybe leave them behind as GPL or remove them if they don't add any value any longer.

It is possible to have a mixed license on composer, so that will be
perfectly possible.

Also when updating the license we should include a more generic description in the source files, see e.g. https://github.com/Seldaek/monolog/blob/master/src/Monolog/Handler/ErrorLogHandler.php#L8

Most of the test images were contributed by others under the GPL. Maybe leave them behind as GPL or remove them if they don't add any value any longer.

@mgeisler I assume the images are used for testing specific EXIF bugs from different cameras and whatnot. If not and they're more general purpose, can we just remove them and submit new ones under LGPL?

@takobell Yeah, they were added back in the day to act as regression tests. Ideally they should also test for specific bugs and quirks as you say, but I think most were added simply to be able to say that PEL has been tested with this or that camera brand.

You'll have to check the details with @lsolesen, but given the above, I think it would be fine to remove the old images now.

@brandonkelly and @takobell A few things to consider if removing the images:

• Rewrite and check the functionality that creates the image tests. We have moved to PHPUnit now, and the old tests were written using simpletest.
• We need to make sure that the test coverage stays the same or improves when switching images.
• The images are fairly old so I think it would be good to get new images. Would probably be good with different camera models and exported from different widely used programs.

But I am all up for you suggestion @takobell

@lsolesen @mgeisler Alternatively we can leave them in and dual license MIT and GPL? Does that mean people can just choose the license they prefer?

@lsolesen @mgeisler OK we've made the following changes:

• The COPYING file containing the GPL license has been replaced with LICENSE.md, which states that the code is dual-licensed under MIT and GPL 3.0, giving devs the choice on which they wish to use when using the code in their projects. The full text of each of those licenses are included in the file under Appendix A and Appendix B, respectively

• Each of the source code files previously containing license information have been updated with the following text:

  For licensing, see LICENSE.md distributed with this source code.
  

This is how CKEditor has executed its own multi-license (GPL, LGPL, and MPL, in its case).

Not sure how to handle assigning only the GPL license to the images within test/image-tests/ directory. Anyone have a clue on that?

Coverage remained the same at 54.713% when pulling 08f5640 on pixelandtonic:feature/lgpl into 1ec296d on lsolesen:master.

I am by no means an expert in licenses. However, what about we just leave the source code to MIT. Then people can do whatever they like with it. Then within the test directory we state in the README.md that the test source is MIT while the images in image-tests and images are GPL2. in image-tests there is already a license stated and a README-file. @brandonkelly How does that sound?

@mgeisler You know more about this stuff, it seems.

@lsolesen Yeah, I agree with you — I'm by no means an expert, but I find it confusing when projects are dual-licensed. Especially so when one license is a "superset" of the other: saying that people can do what they want under the MIT license means that they can use the code for proprietary purposes and that makes the GPL irrelevant.

Put differently: you can already combine MIT code with GPL code, so there's no need to explicitly dual-license it as GPL.

I would much prefer to simply say that the code is MIT licensed, with a note that images have other licenses. Like suggested by @lsolesen.

I think it's not good to license the photos under GPL and the rest of the code under MIT license, because both parts are distributed in the same package. Whenever a derived product includes those files it will be infected by the GPL license.

IMHO the only way is to contact the originators and ask for permission to do the license change or to remove the pictures completely from the sources. As negative effect many important test-cases will disappear - and those test cases are very important to prevent regressions...

Or we could do the package witout the tests. Travis has a nice deploy
feature which might do this automatically.

Den tor. 28. apr. 2016 14.37 skrev Johannes Weberhofer <
notifications@github.com>:

I think it's not good to license the photos under GPL and the rest of the
code under MIT license, because both parts are distributed in the same
package. Whenever a derived product includes those files it will be
infected by the GPL license.

IMHO the only way is to contact the originators and ask for permission to
do the license change or to remove the pictures completely from the
sources. As negative effect many important test-cases will disappear - and
those test cases are very important to prevent regressions...

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#47 (comment)

@weberhofer I'm pretty sure I've seen other projects distribute files under mixed licenses. Just because you get everything in the same tarball, there's no requirement that everything must use the same license. The test images are input files and I don't think the rest of the code is derived from them.

@mgeisler I guess the problem with a mixed license is, for a project that wishes to use the MIT license, they would have to manually remove the GPL-licensed files, which is not very practical when using a package manager like Composer.

@lsolesen Interesting. That might be the best way to go. There's not much point to including the tests in the distribution package in the first place.

I am not sure how deploy works. Do you have some time to investigate?

I'm not sure about this licensing change. I'm sure it's no issue for PEL but possibly for derived work. But if the mentioned files are removed during packaging than it's possibly ok. I don't know how to do it.

@lsolesen @weberhofer I could spend some time looking into removing them from a release. Is this (https://github.com/lsolesen/pel/blob/master/make-release.sh) the latest script that's used for packaging up a release? Looks out-of-date with references to SVN.

@takobell Did you have any chance to look into this, so we could make this happen?