Closed PowerKiKi closed 5 years ago
I agree with re-licensing my contribution(s) under an MIT license.
I agree with re-licensing any code ported from Spreadsheet::WriteExcel under an MIT license.
While composer is a vibrant community, the license acceptance rate is kinda pointless. 1) there are plenty of communities outside of it that are largely or almost exclusively GPL. Drupal, Wordpress, etc. 2) Its not a bandwagon but judgement about your rights and the usage of the software you are writing.
@Niggler At some point Xavier used to have email address [[REDACTED OUT]]. I remember him from way back.
Thanks again @Niggler and @tuupola. I reached out (again) to both emails for Xavier. Hopefully he will see one of them.
I also took the liberty to redact out his email from your post @tuupola, to avoid making it too much public. Even though it just bounced saying that the account does not exists anymore...
The next example is FormulaParser
. The comment and history suggest @maartenba ported the formula parser from the ewbi.develops blog post
. There is no information about the licensing of the original code. info@ewbi.com is an email address listed on the site.
I agree with re-licensing my contribution(s) under an MIT license.
I agree with re-licensing my contribution(s) under an MIT license.
@Niggler if a code has been rewritten, does licensing issue apply for such case? I think the subject of licensing is implementation, not the idea. So, if a code has been copy/paste'd or used as a module, licensing issue has to be resolved; if, for instance, a Perl module is used as an inspiration, isn't it a completely different matter? Same for some example in a blog post: as nothing has been used directly, shouldn't that be OK?
@kamazee It's a tricky question to answer. "Rewriting" includes the extreme of literally retyping code, so there's definitely a "line" and subjective judgment involved. https://blog.codinghorror.com/pick-a-license-any-license/ is a nice blog post summarizing the situation when dealing with blog posts that are missing licenses.
As for existing licensed code like perl modules, porting arguably constitutes a derived work and the original license terms govern the situation (again, it's a subjective line). In the case of dual-licensed modules, the selected license terms should be stated in the source code.
I definitely believe it is better to be safe, especially since the source code to Microsoft Office is available to some people under certain programs like Microsoft's Government Security Program: http://download.microsoft.com/download/B/C/A/BCAFF3F5-5DB5-4AB4-9AAB-5CF0814E0948/GovernmentSecurityProgram.pdf
N.B.: In the JavaScript world, for example, there was a library written by a Microsoft employee that had a funny open-source-incompatible license clause which explicitly granted protection only to use cases for Windows users:
(F) Platform Limitation- The licenses granted in sections 2(A) & 2(B) extend only to the software or derivative works that (1) are run on a Microsoft Windows operating system product, and (2) are not Excluded Products.
https://github.com/stephen-hardy/xlsx.js/blob/master/LICENSE.txt#L22
I agree with re-licensing my contribution(s) under an MIT license.
I agree with re-licensing my contribution(s) under an MIT license.
@Niggler, I sent an email to ewbi.
For everybody else that already replied, thank you, and feel free to unsubscribe from this issue to avoid further notifications.
I agree with re-licensing my contribution(s) under an MIT license, event my contribution currently just one small feature.
On Thu, Aug 17, 2017, 4:41 AM Adrien Crivelli notifications@github.com wrote:
@Niggler https://github.com/niggler, I sent an email to ewbi.
For everybody else that already replied, thank you, and feel free to unsubscribe from this issue to avoid further notifications.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/PHPOffice/PhpSpreadsheet/issues/140#issuecomment-322907679, or mute the thread https://github.com/notifications/unsubscribe-auth/AGrRjUfQR-qGoLzvKj2Oza8szPfJJGAlks5sY2IPgaJpZM4M-jtD .
Regarding the FormulaParser code ported from ewbi.develops, I agree with re-licensing my contribution(s) under an MIT license.
ETA: Maarten Balliauw "ported" my JavaScript implementation to PHP for his PHPExcel project back in May 2007 to avoid "reinventing the wheel". He did a great job, even kept the original comments. It was great to learn today that this stuff's still around and serving a purpose. Good luck! :)
@ewbi while we have your attention, would you be willing to add an MIT attribution to the JS code in your blog post? PHPExcel / PHPSpreadsheet aren't the only projects using code that ultimately traces back to your incredible contribution (you would be surprised by the sheer number of tools and projects that drew from it!)
@PowerKiKi @MarkBaker the next (and most likely longest) example is the Xls Reader. This one is a bit trickier to unwind. My (most likely incomplete) understanding of the history is as follows:
1) The starting point is a java library called excelread
by Andy Khan. Licensed under LGPL v2.1 The original distribution is not available on the archive and the domain has been down for years.
2) A PHP version based on the java library was released. According to the comments, it would have been pear/Spreadsheet_Excel_Reader
. The original author is Vadim Tkachenko but there is a credit to David Sanders. That was available under the PHP license version 3.0. Interestingly, the SourceForge repo also credits Travis Harris but is not mentioned at all in relation to the PEAR entry.
3) The comment appears to match that in the ParseXL version 1.10 ticket. The attribution references other tickets, and I think there was some confusion here. Note: This version has no license attribution whatsoever!
unicode patch by nobody -- My best guess is patch 5 which appears to be source forge user bjaenichen
Some of the email addresses are available by in the links.
MIT is something like a "do what you want" license, while LGPL and (L)AGPL ensures that free software remains free software and it misses the point of ensuring freedom of its users:
https://www.gnu.org/philosophy/open-source-misses-the-point.en.html
@c-schmitz, @CloCkWeRX, @cocowool, @dbonsch, @frost-nzcr4, @k1LoW, @kea, @neclimdul, @nickypn, @odbc, @Quix0r, @roojs, @stevleibelt, @till
Hi, we are still missing your input for the potential change of license from LGPL 2.1 to MIT. Please let us know your opinion, whether you agree or not, so we can reach a conclusion on the matter.
Thanks in advance !
I agree with re-licensing my contribution(s) under an MIT license.
While I don't agree with the re-licencing - could not actually find any justification in the thread.. My contributions (if any) are probably so small that it's probably irrelevant anyway...
@roojs the justification is there, let me know if that makes you change your mind.
In short:
LGPL is the source of a lot confusion when it comes to what is possible
It is somewhat similar to the React license mess where they ended up changing the license (after saying they wouldn't one month prior), because developers were too afraid of what may or may not happen because of React license.
Granted our case is way less dramatic, yet I feel MIT would get rid of all doubts once and for all, without losing anything in return. Because we have to be practical here, LGPL is nice in theory, but we barely have enough manpower to maintain the code, how could we actually actually enforce LGPL ? Where does the time, money and knowledge would come from ?
Since we unfortunately can't, in practice, benefit from LGPL, I don't see why we should add burden to the users.
As I mentioned before, My contributions have been so tiny (if at all...), you can take my objection with a pinch of salt anyway.
I did see this thread a while back, and was a bit perplexed then. From what I gather you are saying having LGPL is putting people off using/contributing to the library. (I doubt this is really the case, as there are not any competing implementation anyway, and most people usually contribute based on need/requirement.)
The main point of LGPL is to encourage (as you rightly point out, they can not really legally be forced to as you don't have the resources) to contribute changes back to the library, rather than taking and not sharing. MIT, is really just a take this, and do what you like with it (except leave the notice in..)
As I said you are free to ignore my objection, as it's pretty pointless.. but I thought I'd just give you a 2c opinion on the thread.
The library lacked so far a maintainer who is able to understand and maintain the code. I know because I tried it myself. At times there were contributions but the patches were often buggy and had to be checked thoroughly, which needed more time than I could spare. I doubt the license change will change anything regarding this situation, but if anyone feels better about it and contributes better code who am I to complain.
If LGPL is confusing to (some?) people, why don't that people go to the FSF(E|A) and ask questions there? MIT is what also @roojs says, take it (your work) and don't give contributions back (which is bad).
@c-schmitz, Mark Baker has been maintaining this lib for at least 6 years. I am pretty confident that he knows it very well. But it's a huge workload and one guy is not enough to also educate newcomers, help them write robust code and unit tests. IMHO what we miss is people contributing non-code stuff, like answer usage questions (issue tracker is full of those), improve the doc, and help crafting good PR.
Of course a change of license will not change much. But, like you said, if it can help a little, then it's worth doing.
It's been almost 3 months since we started asking permissions to contributors, and almost one month since the last reply. At this point I don't expect to get any more replies.
According to our spreadsheet, we reached ~71% of agreements with only 2 "soft" disagreements that might or might not be ignored.
However while the majority was reached, I don't think it is enough, legally speaking, to do the licence change. I am personally not willing to take the risk and I am not willing to wait any longer for hypothetical missing replies. So as far as I am concerned, we will stay with LGPL 2.1.
@MarkBaker, @maartenba, as the original authors, if one of you are willing to take the responsibility and change the license yourself, please be my guest.
71% is too low imo :-( Guess we'll be taying on LGPL 2.1 then.
Thanks to everyone for their efforts!
To my knowlegde you only really have to ask the persons which have still parts of the their source code really existing inside the software, Is this really the case with these missing agreements?
@c-schmitz, I don't know if this is true. And I also don't know how to get a list of authors the most recent lines of the project. Also I am not quite sure about the pertinence of the result if we ask git and it returns the author who last changed indentation on the entire project...
Usually you would check what changes the particular author introduced. I'd bet in most cases it is just a fix or two. Then check if the code in question still exists. If there is none of the code left then there is no case to protect anything in the first place. How many 'authors' are we talking about?
@c-schmitz have a look there, that would be 13 people who didn't answer. If you are willing to do that work, please be my guest.
@PowerKiKi Did you try emailing those who didn't respond? You're missing some names and email addresses at the end of that sheet. Shall I add them here as a Markdown table?
I did contact everybody on the list, at least twice if they didn't respond, either via email, or via GitHub mentions in this thread. Unless you are willing to contact them yourself, it won't be necessary to complete the list. If you do want to work on that, I'll give you write access to the sheet though.
You could do it with git blame
on each file, so some console "magic": . This is maybe not fully optimized, but it should give you a unique list of all recent author's email addresses.$ find * -type f -exec git blame --show-email -w {} \; |grep "@" | cut -d " " -f 3|sort --unique | cut -d "(" -f 2
Update: A "better" one: $ find * -type f -exec git blame --show-email -w {} \;|cut -d "(" -f 2|cut -d "<" -f 2|cut -d ">" -f 1|sort --unique
.
Maybe some sed
instead of cut
is required? I get non-email addresses back, too.
@Quix0r I believe this is what you are looking for:
git ls-files -z |xargs -L 1 -0 git blame --porcelain > all-blame-data
grep -IE '^(author|author-mail) ' all-blame-data | sort -u
But like I said, what is the point of knowing that Mark Baker changed whitespace on the entire project and that I moved every single file around ?
Okay, fair point. Maybe a git reset HEAD~X
before? And thank you for posting better code (not cut
).
How much of a contribution must someone have made for us to require their permission? :confused:
cocowool – 1 commit (PHPOffice/PhpSpreadsheet)
These still exist in the develop
branch.
This appears to be cocowool's 125ea80821d060c769464f5fcd2eef2318a5a31f, with tests added by @PowerKiKi. So, cocowool added a comment, and 19 characters in 1 line. Is that correct?
k1LoW – 1 commit (PHPOffice/PhpSpreadsheet)
I pasted the latest code over the changes made in this commit so that you can see what's changed. Here is the Gist.
neclimdul – 2 commits (PHPOffice/PhpSpreadsheet)
These still exist in the develop
branch.
Moves two }
characters, adds a =
character.
Moves a line, adds a comment, removes a few lines.
odbc – 3 commits (PHPOffice/PhpSpreadsheet)
These still exist in the develop
branch.
Adds 33 characters to 1 line.
Adds 7 characters to the same line as in 1a2a6816fb5bb0e146524ba40aa419695c40136a.
Use
use
sections instead of fully qualified class names 198 additions and 150 deletions.
Aside from some added comments, you could make identical modifications using an automated replacement (e.g. sed
).
kea – 1 commit (PHPOffice/PhpSpreadsheet)
These still exist in the develop
branch.
Without this commit's creation of the unit test file, it adds 2 lines, and modifies two others; if we rewrote that unit test file from scratch (currently 70 lines), are those remaining changes enough for us to need to ask for permission?
IANAL but I expect that every single line of code counts as a contribution. I will not change the licence unless we can get an agreement from everybody, because I really don't want to take any risk for some open-source project. But if somebody else is willing to take the responsibility...
I agree with re-licensing my contribution(s) under an MIT license.
Really unfortunate that this library didn't change to MIT or similar permissive license. Wanted to use this for my dayjob, but can't due to LGPL requirements.. :/
LGPL is actually quite permissive, see https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_from_the_GPL
LGPL has actually a lot of restrictions.
That's why most software libraries and frameworks are now using MIT, BSD or ISC so it is possible to use them in any open source project without having to think about license compatibility problems: to drive adoption. Particularly, it is the very way to allow derivative works in the shipped software.
For the PrestaShop project, the license is OSL, and it is not compatible with LGPL. So having PhpSpreadsheet moving to MIT would be great.
License compatibility issues are a real pain in open source and free softwares. So, the simplest is the license, the more you will have adoption and contributors.
@PowerKiKi I just received a notification about this. Had not seen this earlier. If I need to agree to a license change to MIT, then this is my agreement.
@anton-harvey if the small parts of the code are rewritten by someone who agree to change the license, then, next version can be in MIT.
OK so I checked the entire list of people who told that they accept the change for MIT: agopaul, amironov, ankitm123, bolovincev, c-schmitz, c960657, dmelo, ewbi, frans-beech-it, frost-nzcr4, Gemorroj, helgi, jmcnamara, johndoejdg, kamazee, karak, kea, kifni41, korvinko, Kurounin, maartenba, mingc00, neclimdul, odbc, Progi1984, Slamdunk, stevleibelt, techhead, till, titanrat, tomaszsita, trvrnrth, tsmsogn, tuupola, z38, xnoger, cocowool, dbonsch, k1LoW, nickypn, cweiske, roojs
I removed the @ in order that they are not pinged again. Some of them are listed also for they added a license to some external code (blog post, ...)
People without answer or no clear answer:
So the big challenge is to identify the part of the code written by those people in the current version, or in the latest tag. And then, estimate the time needed to replace it. Some of that work has been done in this comment But maybe that could be worth a new check, the last one is quite old now.
update: remove from the no answer list when a new author tells he agrees to the change.
till just agreed to MIT. I added him in the list.
@ttoine, I'll give you write access to the list if you ask for it
@PowerKiKi from what I can see in the spreadsheet most of guys without answers don't that much contributions. Maybe this could be possible to create one issue per missing github account with the list of things to rewrite, so the work can start ?
TBH, I don't remember what my contributions were. I don't see myself in Contributors
From what I understand, notably from a similar move from jQuery, it would technically be legal to change our license from LGPL to MIT. The reasons for such a move would to get rid of the boilerplate header in all files (which is not always consistent in our case), and make the end-user life easier by choosing a well-known, very permissive and broadly used license.
But I am not a lawyer, and I may be missing something. Is it really doable ? is there anything else to do than edit the files ? should we contact previous contributors ?
@MarkBaker, @maartenba as the two most prominent contributors, would you have any opinion on the matter ?
Also @Progi1984 what was the rationale for choosing LGPL 3 for PhpWord ? I see it was talked about in https://github.com/PHPOffice/PHPWord/issues/211, but would your mind has changed in the last 3 years ?