incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: logo source files
Date Wed, 04 Apr 2012 00:04:58 GMT
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 [] 
Sent: Tuesday, April 03, 2012 13:04
Subject: Re: logo source files

On Tue, Apr 3, 2012 at 3:23 PM, Dennis E. Hamilton

[ ... ]
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.

Also, "Passport without a Visa" is a good article that describes some of
the considerations:


>  - Dennis
> -----Original Message-----
> From: Rob Weir []
> Sent: Tuesday, April 03, 2012 10:10
> To:
> Subject: Re: logo source files
> On Tue, Apr 3, 2012 at 4:00 AM, 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
> >
> >
> +1.  Getting it into SVN makes it easy to get to from the build and the
> website.
> > Juergen
> >

View raw message