Greetings,
As you might recall from the PHPExcel licensing discussion
(https://sourceforge.net/mailarchive/message.php?msg_id=27884122) the
Fedora people were investigating a possible licensing concern with the
tcpdf library we bundle. Nothing has come of that with Fedora, but
apparently the SuSE people have found something they don't like. The
user ChrisWi asked about it in the IRC channel and provided a link to
their bugtracker: https://bugzilla.novell.com/show_bug.cgi?id=736698 --
which requires a login, so he also provided the following text summary:
** begin paste **
phpMyAdmin 3.4.7.1 (and presumably many earlier versions as well) contains
tcpdf. This package claims to be LGPL-3.0+ licensed but contains the
following
clause:
Additionally,
YOU CAN'T REMOVE ANY TCPDF COPYRIGHT NOTICE OR LINK FROM THE
GENERATED PDF DOCUMENTS.
As the LGPL-3.0+ incorporates by reference the GPL-3.0+, sections 7 and
10 of
the GPL-3.0+ are relevant:
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
Accordingly, it may be possible to point out to tcpdf upstream that the
additional term that they apply may be viewed as a 'non-permissive
restriction'
and that you wish to exercise your rights under the GPL-3.0+ to remove that
term from downstream distributions.
If upstream are unwilling to engage in meaningful discussion or take the
view
that the additional restriction is per se not part of the license
because it is
above the license and not incorporated into it, tcpdf should be dropped.
** end paste **
Now again, as I'm sure you're aware, we're not responsible for making
the distributions happy, but it's also in our best interest to try to
resolve these things. Looks to my non-lawyer eye like this is something
to push back on the tcpdf folks. Again, if I'm understanding correctly,
the problem is the additional line added that "YOU CAN'T REMOVE ANY
TCPDF COPYRIGHT NOTICE OR LINK FROM THE GENERATED PDF DOCUMENTS."
Additionally, Google provides a lot of results of people questioning
this.
https://sourceforge.net/projects/tcpdf/forums/forum/435311/topic/3757478
seems to be the best discussion. A discussion regarding the inclusion in
Tiki Wiki
(http://projects.opensource.org/pipermail/license-discuss/2011-November/0000…)
went so far as to bring up the dubious legal position of putting a
(tcpdf) copyright notice on the work of others.
From the tcpdf forums link, it appears the author has no interest in
changing this. To be fair to tcpdf, the only place I see his notice in
the generated PDF is the "PDF Producer" field of the file properties. I
think that's reasonable, but I think the part that concerns the SuSE
folks is the having a non-OSI-endorsed clause appended to a license; if
every project would do that it would be a nightmare to maintain. But
that's just my interpretation.
I've signed up for a Novell account, but I'm still not authorized to
view the bug report directly. At the moment, aside from the gentleman in
IRC, we have no line of communication to them or way of getting updates
on their internal discussion.
Thanks for your thoughts on this...
~isaac
Hi,
Currently the doc says
---
$cfg['MaxRows'] integer
Number of rows displayed when browsing a result set. If the result
set contains more rows, "Previous" and "Next" links will be shown.
---
Due to [0] I suggest this:
---
$cfg['MaxRows'] integer
Number of rows displayed when browsing a result set and no LIMIT
clause is used. If the result set contains more rows, "Previous" and
"Next" links will be shown.
---
I believe that an explicit LIMIT in the query has priority over MaxRows;
this is the current behavior.
[0]
https://sourceforge.net/tracker/index.php?func=detail&aid=3354433&group_id=…
--
Marc Delisle
http://infomarc.info
Welcome to the first beta release for phpMyAdmin 3.5.0; here are the
major new features:
* browse-mode improvements
** grid editing
** remember recent tables
** remember last sort order by table
** flexible column width
** reorder columns
** more compact navigation bar
* AJAXification of many operations
* reorganised server status page, with server monitoring
* improved support for stored routines, events and triggers
* openGIS support
* zoom-search in table search
* Drizzle support
* improved ENUM/SET editor
Details will appear on http://phpmyadmin.net. In a hurry? you can visit
http://sourceforge.net/projects/phpmyadmin to download.
Marc Delisle, for the team
Hi,
I suggest a 3.4.10-rc1 with the seven fixes that are already in. This
could be the last one for 3.4.x.
3.5.0-alpha1 has 8000 downloads so I'm pretty confident about going to beta.
--
Marc Delisle
http://infomarc.info
Hi
I've just noticed that the way I scripted creating STABLE and TESTING
branches is pretty much broken and you can find major breakage in
current TESTING branch. Surely there are ways to bring them to
reasonable shape (STABLE does not seem to be affected for now).
But my question is: Is actually anybody using these branches?
I don't think we're promoting them much to outside world and I don't
think it's usable for developers, so I find them pretty much useless,
but I might be wrong...
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
Hello phpmyadmins,
I am new around here, and I would like to submit a *small bug fix for [0]*.
I have read some pages on the website [1], wiki [2] and took a look at
the patch tracker [3]. I understand that I have to either submit a patch
( created with git format-patch, or with git diff between two branches),
or I can post the link to the branch solving the bug on my forked
phpMyAdmin repo [4].
I did not add a patch on the tracker, because I am not sure if that is
the good way to do it, but if I were to do that, I would probably classify
it as "Category -> Debugging", and "Group -> Finished. Needs basic
tests". Is that ok?
The other option would be to post a comment on the bug tracker [0]
with a link to the branch containing *my proposed fix on my forked *
*PMA repo [5]*. But on my 3464377 branch, I made more commits to
reach the final desired code : a few test commits, then the actual
code fix commit + a white space delete, then a coding style commit
and finally an undo white space deletion commit :). And I'm not sure
if that's ok. Should I try and merge all those commits into one somehow?
So just in case my repo is not good to merge from,* I copied the final *
*diff on pastebin [6]*.
And also, I edited the code in netbeans, so I hope there are no other
differences in the white spaces, or any other coding style related issues,
than the ones I spotted. I think that it should be ok, but again, please
correct me if I am wrong. And, of course, any comments about the
actual fix are more than welcome.
[0] *
https://sourceforge.net/tracker/index.php?func=detail&aid=3464377&group_id=…
*
[1] http://www.phpmyadmin.net/home_page/improve.php
[2] http://wiki.phpmyadmin.net/pma/Development
[3] https://sourceforge.net/tracker/?func=add&group_id=23067&atid=377410
[4] http://repo.or.cz/w/phpmyadmin/alexukf.git
*[5] http://repo.or.cz/w/phpmyadmin/alexukf.git/shortlog/refs/heads/3464377*
*[6] http://pastebin.com/g0CGrhZv*
*
*
Kind regards,
Alex
Hi,
not sure this was discussed but I found a shortcoming when grid-editing
a DATE column: I cannot enter myself the date and am limited to pick a
date from the calendar.
Compare with the traditional edit panel when you can enter a date or
click the calendar icon.
--
Marc Delisle
http://infomarc.info
Hi,
A patch in our tracker [0], proposes to make the frameborder between
the left pane (navi) and right pane (main page), visible so that the
left pane can also be resized in browsers other than Firefox.
Implementing this patch would make the interface more ugly, but I'm
wondering if it would be useful to be able to resize the left pane?
The only two reasons I can think of are
-being able to display very long database/table names
-increase the size of the left pane on a screen with a very small resolution.
If the resizing of the panes would be useful, I think there are better
solutions for resizing the left frame, f.e. with a javascript solution
or a config parameter, to make it work in all browsers. This kind of
solution could also work if we ever would abandon frames and use <div>
to seperate the navi part from the main screen.
What do you think?
[0] http://sourceforge.net/tracker/?func=detail&aid=3473502&group_id=23067&atid…
--
Kind regards,
Dieter Adriaenssens
