On 03/29/12 06:19, Oliver-Rainer Wittmann wrote:
Hi Pedro,
On 28.03.2012 17:23, Pedro Giffuni wrote:
Hello;
Excuse me I don't really want to be involved in this discussion.
I am simply tired of looking those files!
Thx again for your work on these files.
However.. just my $0.02.
On 03/28/12 04:18, Oliver-Rainer Wittmann wrote:
Hi
...
There is already feedback on legal-discuss regarding my post.
A short summary:
- It seems that LICENSE file and NOTICE file of integrated Apache
projects as
3rd party components need to be considered. E.g. Apache APR
- It seems that notices of 3rd party components which are licensed
under the
Apache license need to be considered. E.g. serf
- For our planned binary packages the bundled dictionary extensions
need to be
considered.
If you are interested in further details you may have a look at
http://markmail.org/thread/ze722s7ovb5pjdnn
The thread and particualrly Marvin Humphrey's first reply are very
interesting
but I don't agree with your summary.
It is clear to me that the NOTICE file has only to purposes:
1. To cover for the advertisement clause the classic BSD licenses and
ASL (1-1.1).
I am not an expert here. Thus, let me ask some questions to be sure:
If the advertising clause is included in the use BSD license then we
have cover it in the NOTICE file. Right?
The advertising clause states that the name of the copyright holder
shall not be used to promote the product which uses this software.
No , that's not the advertisement clause: you can identify it because on
the classic BSD license it's the third of 4 clauses. We almost don't have
any code under that license (OpenSSL is the typical example).
Why does this mean that we have to cover it in the NOTICE file?
The advertisement clause is this one:
" 3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the <organization>."
It is somewhat inconvenient for end distributors but there are deep
political
reasons behind the FSF's hate for this clause (somewhat related to
obliterating the individual in favor of a collective entity owning the
code).
2. To inform about probable patent issues.
The above two things are typically the things that make software GPL
incompatible.
My conclusions are:
(1) We are carrying way too much information in our NOTICE and
LICENSE files.
(2) The mere existance of a LICENSE file would indicate we cannot
comply with
the GPL. The GPL, however only applies to distribution not to use.
I think to be consistent with (2) we cannot carry GPL notices, plus
those are not
shipped always. I think the way around that is add a general
disclaimer note
about "alien" extensions that may be included in a binary package
that are under
an independent license but don't constitute derived works.
Thus, I will continue my work on this task:
- First I will create a LICENSE file and a NOTICE file for the
source package
of our release. These will be the files trunk/main/LICENSE and
trunk/main/NOTICE
This must be stripped, Please note that we already carry information
about other
Apache Projects like Tomcat and Commons in our NOTICE file. The AL2
doesn't
have an advertisement clause, so I think almost everything there
should go except
for OpenSSL and maybe the ICC stuff and the Adobe stuff.
- Then I will create a LICENSE file and a NOTICE file for the binary
packages
of our release. I will name them trunk/main/LICENSE-binary-package and
trunk/main/NOTICE-binary-package
You can call make LICENSE addendums but then those vary with the
specific
dictionaries bundled. In the thread there is uncertainty if we should
include
such thing in LICENSE or if we should just note them prominently in the
extensions themselves.
Have you seen William A. Rowe Jr.'s reply on legal-discuss. He stated
that it should be included in the LICENSE file.
OK, I read it. I agree that would be the ideal but still that is not
legally consistent.
IMHO, it's really a bad idea to bundle GPL stuff in the binary packages.
We are about to repeat the PostgreSQL - GNU readline+OpenSSL incident:
http://lwn.net/Articles/428111/
Cheers,
Pedro.
