change license to MIT?

[ghost]

as mentioned by @stof in #200, the other doctrine projects are licensed as MIT. Should this one be relicensed?

I'm opening this ticket as the problem in #200 was actually solved.

[ghost]

ping @beberlei ?

[beberlei]

We would need to ask all the contributors to change the license, its a daunting task.

[ghost]

didn't somebody have script that automated most of it? was it lsmith?

[stof]

it was @beberlei

[ghost]

oh :( well people should know that they probably shouldn't use JMS bundles alongside doctrine migrations then.

EDIT: according to the Free Software Foundation

[beberlei]

I think you misunderstand Apache license. Apache Foundation projects (or any projects that use Apache license) should not depend on LGPL projects. I think you can combine them in your projects.

[ghost]

(L)GPL 3 is fine, (or (L)GPL2+) , but not LGPL2 according to this http://www.apache.org/licenses/GPL-compatibility.html

Remember that symfony used to ship the JMS Bundles, but stopped. It was because of this.

Crell from drupal confirmed this interpretation.

[ghost]

relevant discussion: https://github.com/symfony/symfony-standard/issues/442

[stof]

@jrobeson the difference is that Drupal and other GPL projects were depending on symfony-standard (well, I'm not sure Drupal does as it uses only some components). This is why it caused issues

[ghost]

LGPL 2 (not LGPL 2+) and apache 2.0 code are just plain incompatible (according to the FSF). period.

[beberlei]

@jrobeson the link you are posting is about GPL, not LGPL. also Drupal is GPL, not LGPL.

[beberlei]

@jrobeson Also if you keep quoting the FSF on this, then please link the resource where they are saying this, it would probably clear everything up.

[ghost]

http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

http://osdir.com/ml/php.phing.devel/2008-04/msg00014.html

it does apply to the LGPL too because of the patent termination and indemnification clauses

[kriswallsmith]

👍

[TomasVotruba]

👍

[stof]

@beberlei could you setup your doctrine license change tool again to perform the migration for this repo too ? Having a single doctrine package on LGPL while all others have been migrated to MIT looks weird to me. It even seems weird that this repo was not migrated at the same time than others.

[kingcrunch]

👍 Handling licenses is already annoying enough. It helps, when all projects from one vendor use the same license.

Out of curiosity: There are several contributors, who only contributed 1, or 2 lines. Do you still need their permission, if their changes changed again in the meantime? I ask because licenses are only valid from the moment they were introduced, so this changes, that aren't part of the current development anymore, are not affected, because they are gone. Am I right?

[stof]

@kingcrunch if the code is gone, we indeed don't necessarily need their approval. This is why the tool written by @beberlei allows to mark some commits as not needing to be taken into account for the change. But given that identifying such commits is a manual process, it is easier to ask everyone to give their permission, and then check such commits only for cases where we don't have a permission yet, as it makes the manual work smaller (sending an email to all contributors to ask them for permission is automated)

[abdala]

@stof, @beberlei Email has been sent? Is there anything I can do to help you with that?

[valioDOTch]

any updates? ;)

[stof]

@mikeSimonson @Ocramius what do you think about this task ?

[Ocramius]

@stof this should happen, IMO, but @beberlei has the experience to make it happen (he wrote the license migration poll/thingy). Also, I would really just do it as a matter of consistency with the other doctrine projects (less licenses => simpler).

@mikeSimonson if you agree with this, I'd start by making sure new contributors have some sort of written agreement (basically ask them before merging any pull requests): it will reduce the work required during the migration.

[mikeSimonson]

@stof @Ocramius well we have started working on a v2 of doctrine migrations. Heavily based on a library we wrote under the MIT license http://github.com/baleen. Most of the code if not everything will be thus rewritten under the MIT license.

For me, except bug fix, the 1.3 will be the last with that code base. Thus I am not sure it's worth the effort to find and get an answer from everyone to change the license. Of course if someone put the effort into doing that I will happily release a v1.4.

If I start asking people to release their PR under the MIT license, is it enough to ask their confirmation in the PR ?

[Ocramius]

@mikeSimonson yes, basically make sure that they know that the code will be moved to MIT.

I suggest you chat with @beberlei and with how he'd prefer to approach this (if he wants to)

[stof]

@mikeSimonson I found https://github.com/gsomoza/migrations/tree/baleen which seems to be the WIP of this v2, and I immediately found something broken in it. Where is the proper place to discuss this v2 ?

[mikeSimonson]

@stof post the issue on baleen.

[stof]

the issue is not in baleen, but in the new doctrine/migrations codebase (I haven't yet reviewed the baleen codebase in details, I only looked at its doc)

[mikeSimonson]

@stof Then create a dedicated issue for v2 in doctrine/migrations

[fabpot]

Any news on this topic? Is v2 already planned? I just want to understand the future of this library and what to expect in the coming months. Thanks.

[Ocramius]

You can unlikely expect a stable release within the next month, @fabpot: we didn't even look at the design yet.

[fabpot]

Thanks @Ocramius

[jwage]

I have started working on a 2.0 version in #617. I would like to figure out how to make this happen if possible.

[jwage]

I am starting the work to change the license here #623.

[jwage]

This was successfully completed in #623.