Hi,
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
binary packages.
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
all.
It's likely for me to fail giving a good vendor definition in English.
Let's have a look at wikipedia:
http://en.wikipedia.org/wiki/Vendor_%28supply_chain%29
"'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 :
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
them
- add checksums for these files
- define the dependencies needed to build and/or run LO (zip, cups, libxslt,
etc...)
- define the packages it may conflict with such as staroffice
- specify some configuration options (disable opengl, use system libraries,
etc...)
- 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.
regards,
André
--
Unsubscribe instructions: E-mail to steering-discuss+h...@documentfoundation.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
