Re: [steering-discuss] Vendor string usage in third-party package of LibreOffice
Am 12.05.2011 15:29, schrieb Francois Tigeot:
So in your case, there might be confusion what the "origin of the sofware"
is - you are the vendor, but you are not "TDF".
I'm starting to realize the "vendor" term should be defined: I'm only writing
packaging scripts, and many third-parties could use them to provide finished
The origin of the software, is clearly TDF: the source code is used as-is,
without any modification.
There may be some small platform-specific patches in the future but that's
It's likely for me to fail giving a good vendor definition in English.
Let's have a look at wikipedia:
"'Vendor' generally applies only to the immediate vendor, or the
organization that is paid for the goods, rather than to the original
manufacturer or the organization performing the service if it is
different from the immediate supplier."
In this context you may see TDF as "the original manufacturer" (of the
source code) while you are the "immediate supplier" (of the final
package containing your modifications).
Therefore: It is absolutely ok to use the "LibreOffice" trademark, but
it is questionable to use "The Document Foundation" trademark.
Should I only use "LibreOffice" ? The wording on the about box would give
This product was created by LibreOffice, based on OpenOffice.org, which is
Copyright 2000, 2010 Oracle and/or its affiliates.
Which will be a bit weird...
Why not use something like "NetBSD pkgsrc Team" - this is more or less
what the Linux distributions do. They use "LibreOffice" but a different
vendor string, which proudly states that they did invest some effort to
bring the packages to their users.
Not really: pkgsrc is a framework to manage and build packages. LibreOffice
is build in the same way as a regular developer would do it and the end
result is a binary package, like a .deb or .rpm
What I've been doing so far is:
- make a list of the source code distribution files, as well as where to get
- add checksums for these files
- define the dependencies needed to build and/or run LO (zip, cups, libxslt,
- define the packages it may conflict with such as staroffice
- specify some configuration options (disable opengl, use system libraries,
- tell pkgsrc to launch the build with autogen.sh and gmake
In a way, it's a machine readable specification of the build instructions
available on the developers web page.
Ok, this is beyond my expertise. If it was possible to include all what
is neede in our build environment, so that anybody (any member of TDF)
could do exactly what you do - I'd agree, you use "The Document
Foundation" vendor string. This would of likely mean some work
(integrating your modifications upstream, testing it, maybe making it
generic ...). But by doing all this you would qualify as TDF member -
and this would be agin for me be an indication to use "The Document
Foundation" vendor string.
Anyway - at this point I'd like to see the input of other SC-members who
have a better understanding what happens technically.
Unsubscribe instructions: E-mail to firstname.lastname@example.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/steering-discuss/
All messages sent to this list will be publicly archived and cannot be deleted
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy