do you have strong opinions on open source licenses? would it be a problem to switch this project to MIT or Apache? the problem with lgpl is that if for example i write my own type and entity implementation for some specific customer scenario, i would always be forced by the license to opensource them. even the symfony bundle for it could be debatable, because it is not a pure consumer of the library but also extends the library itself...
btw, create.js is MIT licensed, and one of the reasons why @bergie created hallo is that aloha is GPL...
well, I'm not an expert on these licensing matters, so I'd have to do some research. I don't want to force all code that users CreatePHP to adopt a copyleft license, i.e. I want to support your use-case of creating custom proprietary derived works. On the other hand, I'd like to make sure that the CreatePHP core stays opensource. I always thought that LGPL was specifically designed for this use case (i.e. that you can use the lib in proprietary applications, but the core remains free), but I have never looked into it closely I guess :-)
well, afaik there is some gray areas in LGPL as the boundaries are very difficult between using a library and modifying its behaviour. with MIT you would still be the owner of the code and nobody can make createphp private. the only difference is that it is very clear that anybody can have private code around it and is not forced to publish that code if he does not want to.
and i notice i started this question by asking if you have strong opinions, and then giving my strong opinions :-)
LGPL is very fuzzy when it comes to scripting languages since the "compilation" phase is at run time.
@dbu: From what I've read so far, MIT includes the possibility to re-release the code as proprietary, but again, I'm not an expert, so I might be mis-reading this. How's about the Mozilla Public License? From what I've read, it's a compromise between LGPL and MIT, so that the files covered by the license have to remain under the license (and thus open source), while you can mix it with files that have a different license without problems. Would this work for you?
the big question is .. why do you care? i mean really .. i just don't see the point in worrying.
as for MPL .. not sure would have to check it .. but imho it would be good to keep a handle on the licenses within the IKS stack.
you as the owner of the code can re-release the code under any license you chose anyways, whether it is GPL or MIT or anything else. however, with MIT others would theoretically be allowed to release their variant of the lib as proprietary code if they think its a good idea.
but still nobody can revoke the license you have on this code. meaning this version of createphp is opensource and it can not be undone. the same with MIT, nobody can come and supress createphp, he can just create his fork and not opensource his fork. (which can be legitimate if the only thing the fork does is fix a very specific problem for a customer. apart from that a fork can happen with lgpl as well, but is in both cases stupid as it wastes energy)
@dbu: Sure, nobody will be able to take away my repo, that much is clear. I'm more thinking about "Microsoft Sharepoint CreatePHP Edition featuring 90% copied code" for $1499/year (which is of course very unlikely to ever happen :-)
@lsmith77: Well, maybe I worry too much, it's just that I don't like to take decisions like this lightly. I mean, right now changing the license is simple, but once other stuff depends on it, it becomes quite difficult. Also, I have to admit that I'm a little bit of a copyleft fanboy, MIT always feels like I'm doing other people's work. As far as the IKS stack is concerned: As long as the licenses are compatible, I don't see much of a problem, especially since no other part of the stack has a hard dependency on CreatePHP.
But I don't want to make a big deal out of this. If MIT is the only acceptable license, we'll switch to that (or do dual LGPL/MIT licensing), but if there's a way for the current and potential stakeholders to live with something a bit more copyleft, I'd prefer that.
do you have any significant example of MIT code being taken and as a result significant code contributions not making it to OSS? but to me the crux is that *GPL just doesn't work with interpreted languages .. there is no "linking" and as such the entire license is a gigantic grey area where nobody knows how adding LGPL code really impacts other PHP code.
@flack fully understand you don't want to decide without understand what it means. afaik the name is something else again. i think people can not advertise their product as CreatePHP (resp. you could start a trademark lawsuit on them).
i think if microsoft would include this library, this is the best that can happen to it: it will boost this library a lot and people will look at open source alternatives :-) but seriously i don't expect somebody making a big business out of that library, nobody buys php libraries afaik - on the other hand if somebody really wants to be mean, he can just steal your code and you will never even know.
@bergie you where involved with the IKS stack and happened to write quite some of the js code we leverage for php here. what is your impression?
@lsmith77 AFAIR Microsoft's Kerberos implementation and the TCP/IP stack in some Windows versions come from MIT/BSD licenses, so I guess these could count as examples. I understand your point about *GPL licenses not being made for script languages, which is why I suggested MPL instead.
@bergie, @dbu & everyone else reading this: To keep this discussion from becoming endless, I propose a vote between the following alternatives:
If that is ok with everybody, I suggest y'all vote for one of the two, and the side that has the most votes by Thursday afternoon will be implemented. In case of a draw, I will flip a coin :-)
@flack exactly .. that is the only example i can think of as well .. so in the grand scheme of things it seems like a non issue :)
and btw it does matter how many OSS license a stack brings with it .. since every license needs some research to properly understand. and there are always surprising details (like did you know that GPLv2 is incompatible with Apache?)
i don't enjoy flamewars about licenses. sorry to have triggered it, but i think its good we discussed it.
thanks for the suggestion of dual licensing with MIT and LGPL, +1 on dual license from me. (and my permission to add the MIT license to the code i contributed so far)
@lsmith77 Yes, I read a bit about the LibreOffice licensing discussion recently, and they touched on many of these issues (LibreOffice is also where I got the idea for MPL).
+1 for MIT, as this sort of infrastructure code would benefit from as wide audience as possible. And Create.js is MIT too...
@flack: not too many votes, but seems dual license is the way to go, right? can you update the relevant sections to say it may be used under either LGPL or MIT license? or, being the one who suggested it, shall i do a PR on that?
Switch to dual licenses, closes #7