Le 12/06/2018 à 11:56, Taher Alkhateeb a écrit :
First of all, I think it's always a bad idea to "comment out" any
code, and the general rule of thumb is to prefer deleting.
Mmm, what? I just commented out to test. Your comment makes no sense to me, you
could have avoided it.
Of course it's to be deleted if we get this way, should I have said that for
you to understand, or?
Second, the framework and plugins are two separate projects. You
cannot crash the standalone framework so that the plugins can work,
because you're making the framework depend on plugins.
Right, then the solution, like I suggested before, seems to use the itext 2.1.7 version
which "has no legal issue", compile and run.
com.lowagie.text.* is included in the 3.6.1 BIRT runtime jar that we use, and there is a legal agreement between the BIRT team and Bruno Lowagie to
use this version[1].
Lowagie says there are still legal issues with itext 2.1.7 and older versions as explained at
https://developers.itextpdf.com/question/versions-older-than-5
This post says there is no longer a copy in stackoverflow but actually there is
an archive: https://s.apache.org/4QUU, anyway same text.
So just looking at the license is not enough.
Now something more, I checked the last version (4.7.0) of the BIRT runtine and
it contains com.lowagie.text_2.1.7.v201004222200.jar
Inside the jar I read in the about.html that the original itext-2.1.7.jar. is
used (no modifications) same for itext Asian 1.5.2 version.
There are more legal information in about_files\misc_licenses.txt and as far as I understand the only IP infringement would be to use itext-2.1.7.jar
in a nuclear context:
<<You acknowledge that this software is not designed or intended for
use in the design, construction, operation or maintenance of any
nuclear facility.>>
So for me, as long as we warn our users about this nuclear restriction there
should be no problem using com.lowagie.text_2.1.7.v201004222200.jar
Please check the content of about_files\misc_licenses.txt in case I missed
something.
Of course we should ask the legal team before taking a formal decision about it.
I think we have now enough material to ask, and I'll create a LEGAL Jira in a
week. Please speak before if you think I missed something
Jacques
[1] Damned I can't find it again, but anyway it's not the problem. The problem
is possible IP infringement in any itext versions before 5.
On Tue, Jun 12, 2018 at 11:45 AM, Jacques Le Roux
<jacques.le.r...@les7arts.com> wrote:
Le 11/06/2018 à 20:31, Taher Alkhateeb a écrit :
There are 18 emails so far in this thread of which 13 are yours.
- You mentioned stuff from wikipedia
- then you mentioned stuff about licensing
- then you switched to birt
- then you talked about the author
- then you go back to questioning how to render PDFs in BIRT
- then you talk about your test logs for PDF rendering in BIRT (or
something like that)
- then you talk about the gradle cache
- then you talk about digital signatures
- then you talk about discussing things with apache legal
- then you ask people for their opinion
- then you go back to BIRT
So to answer your question, YES, it's very hard to read you :) Many of
your emails are long with lots of URLs and jump around multiple
topics. I personally cannot keep up, and that's why when you present a
question to the community, I have to ask you to pin down exactly what
you want.
Yes legal question matters and are often a delicate matter to handle. So I
ferreted around for clues and reported what I found while doing it.
I agree it's maybe not the best way to interact with the ML. I was unsure of
the facts, so shared to hopefully get some help from the ML.
I'll now try to summarize in this message
Now back to this thread: I'm always in favor of completely removing
libraries where possible. This means refactoring CompDocServices.java
and PdfSurveyServices.java. I'm not sure how much work would that be,
but if it is a lot of work, then the work that I proposed might be a
quick fix for now (exclusion in gradle).
At 1st glance your idea seems the best quick solution. But if you read my
messages you will see that even using itext 4.2.0 is legally not a good
idea.
So while ferreting around I found that I was able to comment it out also in
Gradle build: "//compile 'com.lowagie:itext:4.2.0'"
I mean doing so does not prevent Birt to render PDF files. So I wondered why
and finally found that the version com.lowagie.text 2.1.7, *which has no
legal issues*, is embedded in org.eclipse.birt.runtime.3_7_1
You may find it in your cache, for me it's in
Z:\Gradle\caches\modules-2\metadata-2.16\descriptors\org.eclipse.birt.runtime.3_7_1\com.lowagie.text
So if you remove all itext related files in your Gradle cache you will still
have lowagie files, for me it's at
Z:\Gradle\caches\modules-2\files-2.1\org.eclipse.birt.runtime.3_7_1\com.lowagie.text\2.1.7\18d4c7c2014447eacfd00c65c717b3cfc422407b\com.lowagie.text-2.1.7.jar
When I look for source this is also what Eclipse reports.
So I believe we can get rid of "compile 'com.lowagie:itext:4.2.0'" and Birt
continues to work and render PDFs. For advanced features, users need to buy
a commercial version of itext.
For me that seems the best OOTB solution. I hope this is clear enough, else
please ask :)
Jacques
On Mon, Jun 11, 2018 at 8:25 PM, Jacques Le Roux
<jacques.le.r...@les7arts.com> wrote:
No, I'm suggesting to drop itext as a whole, not only itextpdf.
Is it so difficult to read me :-o ?
I 1st spoke about "itext/4.2.0" (not itextpdf at all). Then I suggested
to
remove "it".
<<Also from few tests I did, it seems we don't need it to render PDF with
Birt. Please confirm...>>
I believe (it's no clear from Birt side) itext is something we drag from
the
1st contribution of Birt in OFBiz. And Birt is now able to render PDF w/o
itext.
In some edge cases (at least: digital signature[1], 4 bytes UTF-8[2])
users
would still need to use itext. See my previous last message for other
details:
<<Since it works for me w/ "compile 'com.lowagie:itext" commented out
after
clearing the Gradle cache from all itext files>>
Jacques
[1] https://s.apache.org/b2sQ
[2] https://s.apache.org/Ib78
Le 11/06/2018 à 16:37, Taher Alkhateeb a écrit :
I'm a bit lost. What are you _exactly_ proposing to do here? Are you
suggesting my exclusion syntax above (BTW better remove the version),
or are you suggesting something else?
On Mon, Jun 11, 2018 at 3:10 PM, Jacques Le Roux
<jacques.le.r...@les7arts.com> wrote:
Le 08/06/2018 à 16:29, Jacques Le Roux a écrit :
Are we sure there are no legal issues doing so?
It seems OK at
https://mvnrepository.com/artifact/com.lowagie/itext/4.2.0
(MPL)
But reading
https://developers.itextpdf.com/question/versions-older-than-5
which applies also to 4.2.0 (see bottom "Some people claim that they
use
iText 4.2.0, but that version has never been officially released")
itext
seems a legal issue globally (not only itextpdf)
Maybe we should ask legal?
Also from few tests I did, it seems we don't need it to render PDF
with
Birt. Please confirm...
Did someone else tests?
Since it works for me w/ "compile 'com.lowagie:itext" commented out
after
clearing the Gradle cache from all itext files I believe it should work
for
everyone else. Please confirm, should I open a Jira now?
Now if users are of need of itext for other reasons (I found a couple
of
them Googling) they should take their responsibility. What are other
opinions here?
Jacques
Jacques
Le 08/06/2018 à 16:03, Scott Gray a écrit :
Thanks Taher! Perfect simple solution.
Regards
Scott
On Fri, 8 Jun 2018, 23:19 Taher Alkhateeb,
<slidingfilame...@gmail.com>
wrote:
So we exclude the transitive dependency in build.gradle and if
everything
works then we're fine.
Syntax:
compile('com.lowagie:itext:4.2.0') {
exclude 'com.itextpdf:itextpdf:5.5.6'
}
On Fri, Jun 8, 2018, 11:40 AM Scott Gray
<scott.g...@hotwaxsystems.com>
wrote:
Hey Jacques,
Maybe I wasn't clear, OFBiz is downloading 5.5.6 as a dependency of
4.2.0,
does it make sense?
Regards
Scott
On Fri, 8 Jun 2018, 19:30 Jacques Le Roux,
<jacques.le.r...@les7arts.com
wrote:
I suggest this comment, a Jira seems appropriate
- compile 'com.lowagie:itext:4.2.0'
+ compile 'com.lowagie:itext:4.2.0' // don't update to 5+
because
of
license change
Jacques
Le 08/06/2018 à 09:26, Jacques Le Roux a écrit :
Le 08/06/2018 à 09:24, Jacques Le Roux a écrit :
Hi Scott,
Reading Wikipedia It's OK as long as we don't update to a
version
= 5
https://en.wikipedia.org/wiki/IText
Here is another source for MPL licensing:
https://www.eclipse.org/forums/index.php/t/175386/
<<The source code was initially distributed as open source under
the
Mozilla Public License <
https://en.wikipedia.org/wiki/Mozilla_Public_License>
or the GNU Library General Public License <
https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html> open
source
licenses. However, as of version
5.0.0 (released Dec 7, 2009) it is distributed under the Affero
General
Public License
<https://en.wikipedia.org/wiki/Affero_General_Public_License>
version
3.>>
MPL being OK as binary
Jacques
Le 08/06/2018 à 03:57, Scott Gray a écrit :
Hi All,
I just noticed that the iText maven bundle is a bit tricksy and
includes
iText 5.6.6 as a dependency, with the latter being GPL
licensed.
You
can
see it by running "./gradlew -q dependencies":
+--- com.lowagie:itext:4.2.0
| \--- com.itextpdf:itextpdf:5.5.6
I haven't checked to see if the later version is actually used
by
our
code
and I'm not sure if merely downloading it causes licensing
issues,
but
I
thought I'd bring the question here in case anyone else has
already
looked
into it. Not sure what the work-around would be if it is an
issue.
Regards
Scott
