Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index

Re: [steering-discuss] Vendor string usage in third-party package of LibreOffice


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+help@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.