You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Kevin Grignon <ke...@gmail.com> on 2012/04/03 09:41:06 UTC
Re: logo source files
@Drew
Where do we keep the source files for the logos?
Thoughts?
Kevin
RE: logo source files
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Good points.
I am more concerned with careless and/or petty misrepresentation. I would like to make it easier for someone who works with the code to recognize what is needed to differentiate what they are producing. It is a variant of the condition which has category-B software be handled the way it is at Apache. In this particular case it seems valuable to me that the source release is something that helps downstream producers of binaries, including ourselves, get it right. A casual use of the build process should perhaps produce something that does not appear the same as a released AOO binary.
With regard to intentional passing-off, I agree that more serious precautions are required to establish the provenance of binaries distributed by AOO and in having folks be able to tell the difference and, of course, find the goods in reliable ways. And other downstream producers of distributions should be able to accomplish the same thing by establishing the provenance of their binary distributions.
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Tuesday, April 03, 2012 13:12
To: ooo-dev@incubator.apache.org
Subject: Re: logo source files
Just a quick tag to the above. We need to be careful whether we trying to
solve a communications problem or a legal problem.
If we're talking about inadvertent trademark misuse, then we have two
lightweight solutions:
1) Make it harder for someone to accidentally misuse the trademark via
education, but also by not encouraging using of our core marks, but instead
encouraging use of separate "community marks" that are not also used to
identify our products. So segregation of two kinds of logos.
2) Handle with education and friendly contacts those who do inadvertently
infringe.
If we're talking about intentional misuse of the marks, then that is an
entirely different issue. Playing around with where we put the logos,
whether in the trunk or in another directory, or any other "soft"
technological teams will have almost zero impact. If someone wants to
misuse the trademark then they will easily overcome these inconveniences.
The keys to dealing with intentional misuse are:
1) A documented trademark policy that makes it clear which uses are
permitted and which are not.
2) Strong methods, cryptographic methods, to ensure that our official
releases can be identified.
3) User education, so they know to look for such official releases.
Does this make sense?
-Rob
Re: logo source files
Posted by Rob Weir <ro...@apache.org>.
Just a quick tag to the above. We need to be careful whether we trying to
solve a communications problem or a legal problem.
If we're talking about inadvertent trademark misuse, then we have two
lightweight solutions:
1) Make it harder for someone to accidentally misuse the trademark via
education, but also by not encouraging using of our core marks, but instead
encouraging use of separate "community marks" that are not also used to
identify our products. So segregation of two kinds of logos.
2) Handle with education and friendly contacts those who do inadvertently
infringe.
If we're talking about intentional misuse of the marks, then that is an
entirely different issue. Playing around with where we put the logos,
whether in the trunk or in another directory, or any other "soft"
technological teams will have almost zero impact. If someone wants to
misuse the trademark then they will easily overcome these inconveniences.
The keys to dealing with intentional misuse are:
1) A documented trademark policy that makes it clear which uses are
permitted and which are not.
2) Strong methods, cryptographic methods, to ensure that our official
releases can be identified.
3) User education, so they know to look for such official releases.
Does this make sense?
-Rob
RE: logo source files
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I think the problem of having material with restrictions on its use in the source release is a greater concern along several dimensions. I see you have another post that focuses on that.
I think something like what Mozilla does is appropriate, without knowing too much about it. That fits the notion that binaries are, relative to the source release, a downstream product (even if it is handled by build options).
- Dennis
Incidental Technical Nits:
1. AFAIK two consecutive builds on Windows always have different digest values. It has to do with the timestamps that are injected into code artifacts such as .obj files. The odds of differences for a build done on a different platform are even greater.
2. And, of course, introduction of a code signature into a binary will result in a different digest than on the unsigned binary and a binary distributed by anyone else. It is not possible to lift the signature from one build and slide it into another, presumably because of (1) at least. I favor signed code on Windows binaries because (1) they were the Sun/Oracle practice and (2) they fit into the Windows ecosystem for authenticating installs on consumer systems.
(1) creates a problem with regard to being able to confirm that a bit-for-bit build replication has been created, and interesting problem in forensics work. Replication is desirable if the goal is simply to confirm that a build from the source agrees with the distributed binaries. (There are ways to filter the timestamps and check other aspects for agreement, but the digest values don't serve that purpose and there are features that can be employed in the source code that will compel differences in the binary as well.)
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Tuesday, April 03, 2012 13:04
To: ooo-dev@incubator.apache.org
Subject: Re: logo source files
On Tue, Apr 3, 2012 at 3:23 PM, Dennis E. Hamilton
<de...@acm.org>wrote:
[ ... ]
If the MD5's match, who cares where it was built? If the MD5's do not
match then they are distinguishable. (For MD5's you could substitute code
signing for a more end-user friendly form of the same thing.)
> There is this odd hitch when binaries are built by someone else, even
> without modification, but without preservation of provenance and
> authenticity. Yet they are not distinguished from "the real thing."
>
>
Ditto. If the hashes match, then it is the "real thing", for all intents
and purposes.
> There is also the problem that, when someone modifies the source and the
> build, that the default is for the resulting binary to be
> indistinguishable, in terms of surface features and the presence of
> identifying information, from the project-created binary distribution.
>
>
Ditto. In that case the hashes don't match so it would be distinguishable.
> I'm also not clear that logos and related artifacts qualify as open-source
> concerning the trademark issues.
>
> I don't know how to crack that strange entanglement.
>
>
Look at what Mozilla does, for example. The default build options do not
include the project logos.
> I can see it working if it were considered that even our binary releases
> are downstream from the Apache release and have some essential
> customizations including being digitally signed and authenticated in other
> ways. Then placeholders could appear in the released source for
> binary-distribution items (some other content being provided instead) that
> are to be provided/customized by any downstream producer, even ourselves.
>
> And then I can't figure out how the binary can be tied to the exact source
> it was produced from.
>
>
That is not really the issue, is it? The issue is how a user can
distinguish an Apache release from something that is not an Apache
release. The PMC is responsible for ensuring that the binary package was
derived from the source.
> Arghh.
>
> I keep thinking this must have been dealt with in the production of other
> user-facing binary distributions from open-source code releases. Anyone
> have any pointers?
>
>
Mozilla is a good example.
http://www.mozilla.org/foundation/trademarks/policy.html
Also, "Passport without a Visa" is a good article that describes some of
the considerations:
http://www.ifosslr.org/ifosslr/article/view/11/37
-Rob
> - Dennis
>
>
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Tuesday, April 03, 2012 10:10
> To: ooo-dev@incubator.apache.org
> Subject: Re: logo source files
>
> On Tue, Apr 3, 2012 at 4:00 AM, Jürgen Schmidt
> <jo...@googlemail.com>wrote:
>
> > On 4/3/12 9:41 AM, Kevin Grignon wrote:
> >
> >> @Drew
> >>
> >> Where do we keep the source files for the logos?
> >>
> >>
> > I would like to suggest that we should create a new place for this kind
> of
> > stuff besides trunk
> >
> >
> +1. Getting it into SVN makes it easy to get to from the build and the
> website.
>
>
> > Juergen
> >
>
>
Re: logo source files
Posted by Andrea Pescetti <pe...@apache.org>.
Rob Weir wrote:
> On Tue, Apr 3, 2012 at 3:23 PM, Dennis E. Hamilton wrote:
>> I'm also not clear that logos and related artifacts qualify as open-source
>> concerning the trademark issues.
>> I don't know how to crack that strange entanglement.
> Look at what Mozilla does, for example. The default build options do not
> include the project logos.
This seems reasonable. A build should only include official branding if
a non-default build option is specified. This mitigates the risk of
people making minor code modifications and inadvertently breaking the
trademark/logo policies.
Regards,
Andrea.
Re: logo source files
Posted by Rob Weir <ro...@apache.org>.
On Tue, Apr 3, 2012 at 3:23 PM, Dennis E. Hamilton
<de...@acm.org>wrote:
> There's something that nags at me about logos and similar materials being
> part of the source-code release (that, I am told, is *the* release in terms
> of Apache principles).
>
> It is natural to have such artifacts in the SVN tree because it is
> convenient and it probably feels essential to have the released source-code
> be the precise source for the project-created binary distributions.
>
> On the other hand, while it is desirable for folks to be able to reproduce
> our build, and have access to the source that was used, that they would end
> up having something that can be claimed to be the authentic project-created
> binary distribution. Yet it will appear indistinguishable from it.
>
>
If the MD5's match, who cares where it was built? If the MD5's do not
match then they are distinguishable. (For MD5's you could substitute code
signing for a more end-user friendly form of the same thing.)
> There is this odd hitch when binaries are built by someone else, even
> without modification, but without preservation of provenance and
> authenticity. Yet they are not distinguished from "the real thing."
>
>
Ditto. If the hashes match, then it is the "real thing", for all intents
and purposes.
> There is also the problem that, when someone modifies the source and the
> build, that the default is for the resulting binary to be
> indistinguishable, in terms of surface features and the presence of
> identifying information, from the project-created binary distribution.
>
>
Ditto. In that case the hashes don't match so it would be distinguishable.
> I'm also not clear that logos and related artifacts qualify as open-source
> concerning the trademark issues.
>
> I don't know how to crack that strange entanglement.
>
>
Look at what Mozilla does, for example. The default build options do not
include the project logos.
> I can see it working if it were considered that even our binary releases
> are downstream from the Apache release and have some essential
> customizations including being digitally signed and authenticated in other
> ways. Then placeholders could appear in the released source for
> binary-distribution items (some other content being provided instead) that
> are to be provided/customized by any downstream producer, even ourselves.
>
> And then I can't figure out how the binary can be tied to the exact source
> it was produced from.
>
>
That is not really the issue, is it? The issue is how a user can
distinguish an Apache release from something that is not an Apache
release. The PMC is responsible for ensuring that the binary package was
derived from the source.
> Arghh.
>
> I keep thinking this must have been dealt with in the production of other
> user-facing binary distributions from open-source code releases. Anyone
> have any pointers?
>
>
Mozilla is a good example.
http://www.mozilla.org/foundation/trademarks/policy.html
Also, "Passport without a Visa" is a good article that describes some of
the considerations:
http://www.ifosslr.org/ifosslr/article/view/11/37
-Rob
> - Dennis
>
>
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Tuesday, April 03, 2012 10:10
> To: ooo-dev@incubator.apache.org
> Subject: Re: logo source files
>
> On Tue, Apr 3, 2012 at 4:00 AM, Jürgen Schmidt
> <jo...@googlemail.com>wrote:
>
> > On 4/3/12 9:41 AM, Kevin Grignon wrote:
> >
> >> @Drew
> >>
> >> Where do we keep the source files for the logos?
> >>
> >>
> > I would like to suggest that we should create a new place for this kind
> of
> > stuff besides trunk
> >
> >
> +1. Getting it into SVN makes it easy to get to from the build and the
> website.
>
>
> > Juergen
> >
>
>
RE: logo source files
Posted by "Dennis E. Hamilton" <de...@acm.org>.
There's something that nags at me about logos and similar materials being part of the source-code release (that, I am told, is *the* release in terms of Apache principles).
It is natural to have such artifacts in the SVN tree because it is convenient and it probably feels essential to have the released source-code be the precise source for the project-created binary distributions.
On the other hand, while it is desirable for folks to be able to reproduce our build, and have access to the source that was used, that they would end up having something that can be claimed to be the authentic project-created binary distribution. Yet it will appear indistinguishable from it.
There is this odd hitch when binaries are built by someone else, even without modification, but without preservation of provenance and authenticity. Yet they are not distinguished from "the real thing."
There is also the problem that, when someone modifies the source and the build, that the default is for the resulting binary to be indistinguishable, in terms of surface features and the presence of identifying information, from the project-created binary distribution.
I'm also not clear that logos and related artifacts qualify as open-source concerning the trademark issues.
I don't know how to crack that strange entanglement.
I can see it working if it were considered that even our binary releases are downstream from the Apache release and have some essential customizations including being digitally signed and authenticated in other ways. Then placeholders could appear in the released source for binary-distribution items (some other content being provided instead) that are to be provided/customized by any downstream producer, even ourselves.
And then I can't figure out how the binary can be tied to the exact source it was produced from.
Arghh.
I keep thinking this must have been dealt with in the production of other user-facing binary distributions from open-source code releases. Anyone have any pointers?
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Tuesday, April 03, 2012 10:10
To: ooo-dev@incubator.apache.org
Subject: Re: logo source files
On Tue, Apr 3, 2012 at 4:00 AM, Jürgen Schmidt
<jo...@googlemail.com>wrote:
> On 4/3/12 9:41 AM, Kevin Grignon wrote:
>
>> @Drew
>>
>> Where do we keep the source files for the logos?
>>
>>
> I would like to suggest that we should create a new place for this kind of
> stuff besides trunk
>
>
+1. Getting it into SVN makes it easy to get to from the build and the
website.
> Juergen
>
Re: logo source files
Posted by Rob Weir <ro...@apache.org>.
On Tue, Apr 3, 2012 at 1:33 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Apr 3, 2012, at 10:10 AM, Rob Weir wrote:
>
> > On Tue, Apr 3, 2012 at 4:00 AM, Jürgen Schmidt
> > <jo...@googlemail.com>wrote:
> >
> >> On 4/3/12 9:41 AM, Kevin Grignon wrote:
> >>
> >>> @Drew
> >>>
> >>> Where do we keep the source files for the logos?
> >>>
> >>>
> >> I would like to suggest that we should create a new place for this kind
> of
> >> stuff besides trunk
> >>
> >>
> > +1. Getting it into SVN makes it easy to get to from the build and the
> > website.
>
> The logo is used in the build and is part of the release. We have the
> difficult question here about distributing logos that are trademarks. They
> are included in our convenience binaries and installers and distributions
> go out, etc. A corporation might make internal changes and re-roll the
> package, these may be slight or be drastic.
>
>
The logo files may be included in a the release, but Clause 6 of the ALv2
gives only limited use of those trademarks, So if someone did take the
code and make significant changes to it, they do not necessarily have the
rights to still use the logos. They certainly have the rights to change
the logo to one of their own.
> At what point does the name and logo have to change? How do we make it
> easy for the downstream provider to fulfill any requirement like this?
>
>
I think that is the key question -- how do we make it easy to rebrand?
With Symphony, for example, we made this very easy. Not need to rebuild at
all. We did it with a plugin, so making a RobOffice or DaveOffice would be
within reach of anyone:
http://www-03.ibm.com/software/lotus/symphony/plugin.nsf/web_DisplayPlugin?openform&unid=22E742258B098B2A852577C30027A24D&category=Miscellaneous&form=home
> For AOO 4.0 do we need a build switch that will replace all AOO graphics
> with "AOO inside" / user provided graphics?
>
>
Build option or something easier if possible.
> Should there be an ODF conformance test?
>
>
Whatever the rules are they must be easy to explain and easy to implement.
> The rules must translate to many languages without becoming ambiguous.
>
> Rob and I did a thought experiment a couple of months ago on what is AOO
> and what is not. I think that we should revisit when the current
> discussions on general@i.a.o reach a conclusion. Dennis has cataloged
> many (all?) of the logo's appearances in the UI.
>
> Regards,
> Dave
>
> >
> >
> >> Juergen
> >>
>
>
Re: logo source files
Posted by Dave Fisher <da...@comcast.net>.
On Apr 3, 2012, at 10:10 AM, Rob Weir wrote:
> On Tue, Apr 3, 2012 at 4:00 AM, Jürgen Schmidt
> <jo...@googlemail.com>wrote:
>
>> On 4/3/12 9:41 AM, Kevin Grignon wrote:
>>
>>> @Drew
>>>
>>> Where do we keep the source files for the logos?
>>>
>>>
>> I would like to suggest that we should create a new place for this kind of
>> stuff besides trunk
>>
>>
> +1. Getting it into SVN makes it easy to get to from the build and the
> website.
The logo is used in the build and is part of the release. We have the difficult question here about distributing logos that are trademarks. They are included in our convenience binaries and installers and distributions go out, etc. A corporation might make internal changes and re-roll the package, these may be slight or be drastic.
At what point does the name and logo have to change? How do we make it easy for the downstream provider to fulfill any requirement like this?
For AOO 4.0 do we need a build switch that will replace all AOO graphics with "AOO inside" / user provided graphics?
Should there be an ODF conformance test?
Whatever the rules are they must be easy to explain and easy to implement. The rules must translate to many languages without becoming ambiguous.
Rob and I did a thought experiment a couple of months ago on what is AOO and what is not. I think that we should revisit when the current discussions on general@i.a.o reach a conclusion. Dennis has cataloged many (all?) of the logo's appearances in the UI.
Regards,
Dave
>
>
>> Juergen
>>
Re: logo source files
Posted by Rob Weir <ro...@apache.org>.
On Tue, Apr 3, 2012 at 4:00 AM, Jürgen Schmidt
<jo...@googlemail.com>wrote:
> On 4/3/12 9:41 AM, Kevin Grignon wrote:
>
>> @Drew
>>
>> Where do we keep the source files for the logos?
>>
>>
> I would like to suggest that we should create a new place for this kind of
> stuff besides trunk
>
>
+1. Getting it into SVN makes it easy to get to from the build and the
website.
> Juergen
>
Re: logo source files
Posted by Kay Schenk <ka...@gmail.com>.
On 04/03/2012 05:31 AM, � wrote:
> On 4/3/12 1:54 PM, Andre Fischer wrote:
>> On 03.04.2012 10:00, J�rgen Schmidt wrote:
>>> On 4/3/12 9:41 AM, Kevin Grignon wrote:
>>>> @Drew
>>>>
>>>> Where do we keep the source files for the logos?
>>>>
>>>
>>> I would like to suggest that we should create a new place for this kind
>>> of stuff besides trunk
>>
>> Why not inside trunk?
>
> well I have thought about general stuff that goes in this direction.
> Means art , design file sfor logos, icons, flyers, etc.
>
> Ideally we would have a CMS where we could easy manage such content on a
> higher level (no scm). Would make it easier for many people.
>
> Juergen
Juergen--
I think some of what you're suggesting may actually be happening via the
Marketing wiki area...
http://wiki.services.openoffice.org/wiki/Marketing
But it's also clear from the wiki page that the intention was to
"migrate", at least for logos, some materials to the marketing area on
the web server. So, I understand what you're saying but even if some
materials are developed on the wiki, I don't think we'd want to link to
them from the web server unless they were put on the web server by a
designated commtter. This being said, it seems we do need to include
marketing efforts in our "Get Involved" page.
--
------------------------------------------------------------------------
MzK
"Women and cats will do as they please,
and men and dogs should relax and get used to the idea."
-- Robert Heinlein
Re: logo source files
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 4/3/12 1:54 PM, Andre Fischer wrote:
> On 03.04.2012 10:00, Jürgen Schmidt wrote:
>> On 4/3/12 9:41 AM, Kevin Grignon wrote:
>>> @Drew
>>>
>>> Where do we keep the source files for the logos?
>>>
>>
>> I would like to suggest that we should create a new place for this kind
>> of stuff besides trunk
>
> Why not inside trunk?
well I have thought about general stuff that goes in this direction.
Means art , design file sfor logos, icons, flyers, etc.
Ideally we would have a CMS where we could easy manage such content on a
higher level (no scm). Would make it easier for many people.
Juergen
Re: logo source files
Posted by Andre Fischer <af...@a-w-f.de>.
On 03.04.2012 10:00, Jürgen Schmidt wrote:
> On 4/3/12 9:41 AM, Kevin Grignon wrote:
>> @Drew
>>
>> Where do we keep the source files for the logos?
>>
>
> I would like to suggest that we should create a new place for this kind
> of stuff besides trunk
Why not inside trunk?
-Andre
Re: logo source files
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 4/3/12 9:41 AM, Kevin Grignon wrote:
> @Drew
>
> Where do we keep the source files for the logos?
>
I would like to suggest that we should create a new place for this kind
of stuff besides trunk
Juergen