incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: PROPOSAL (was Re: Category-B tarballs in SVN )
Date Mon, 16 Jan 2012 21:23:34 GMT
On Mon, Jan 16, 2012 at 11:17 AM, Pedro Giffuni <pfg@apache.org> wrote:
> Hi Rob;
>
> I specifically avoided answering to this on Sunday because
> in my religious beliefs it is a day to rest and I didn't
> really want to spend time on this.
>
> Since the time this was posted I think I have seen the light
> (TM) and I am willing to share it with you if you have the
> patience.
>
> The comments that follow are NOT meant for the faint of
> heart if you are likely to have strong feelings about this
> please STOP READING NOW.
>
> Also, if you are still here, remember ... don't kill
> $MESSENGER.
>
> --- Sab 14/1/12, Rob Weir <robweir@apache.org> ha scritto:
>
>>
>> OK, though this is solving a problem we don't really have,
>> right?
>> Although we have not yet built a script to produce a source
>> package per Apache rules, when we do it will not include
>> any of the /ext-src modules, correct?  It won't include
>> the category-a and it will not include the category-b
>> either?  What would be the point, since the
>> build script brings down what it needs via the bootstrap,
>> per the configuration flags used?  So if we really want to
>> give proper notice to the person downloading our source
>> release, this needs to be done:
>
> We do have to include Category-A in the release or the
> release wont build. Separation has to happen.
>

I was talking about source packages.  They are not required to include
everything that needed to produce the binary package. For example, we
don't include Visual C++ or gcc or a copy of Microsoft Windows.
Generally, tools and libraries that are commonly available we treat as
a pre-requisite.

With category-a source code, I think from a policy perspective, we
could include the source in our release, we could require the user to
download manually as a per-requisite, or we could have the build
scripts do this automatically, from an external server or an Apache
server.

> Here is the first big flaw in your reasoning: there is no
> such thing as a source release or a binary release, there
> is simply a release.
>
> Let me explain it this way: long, long ago, before the

<snipping a long historical digression>

Yes, I believe we all know and understand this.  That is why I've been
using the terms "source package" and "binary package".  An Apache
"release" would include at least the source package.  The current plan
for AOO is to have both.


>
>
>>
>> I have no objections if you want to shuffle things around
>> in the directory structure, and update bootstrap logic
>> accordingly.
>
> "shuffling" things is not a problem but I don't think
> updating the bootstrap logic was mandatory. Our releases
> have to build on their own and as you note the sources for
> Category B stuff are not included anyways, but let me point
> out the second big failure in your reasoning.
>
> As I said before there is no such thing as "source releases"
> or "binary releases" and such terms don't appear anywhere in
> the the Apache licensing policies:
>
> http://www.apache.org/legal/3party.html
>

That URL is for an earlier draft of the policy.  You really should be
referencing the latest version of the policy here:

http://www.apache.org/legal/resolved.html#category-b

> Now, this phrase concerning Category-B has received a particular
> wrong reading:
>
> "Code that is more substantial, more volatile, or not directly
> consumed at runtime in source form may only be distributed in
> binary form."
>

That sentence does not exist in the actual policy.   That is only in the draft.

> We, and particularly you, have read this as a prohibition to

Oh, I didn't read it it all, since that is in the draft version only.

> include MPL'd code in "source release" but the truth is that
> it is a prohibition to distribute Category-B software *at
> all*. Distribution certainly includes subversion.
>

http://www.apache.org/legal/resolved.html#category-b

> The point is further clarified:
> "In addition, C-based projects may have difficulty using works
> under these licenses since they would have to deal with
> platform-specific binaries, rather than just distributing
> source that can be built on most any platform."
>

Again, this is not in the real policy.

> This last clarification has an upside: we can include in
> our releases (and therefore in SVN) platform independent files
> like Java bytecode and fonts under a Category-B license.
>

In any case, I think we've found one source of the confusion here.

Take a look at the live version of the policy (it does get updated
from time to time) and let me know if you still see policy concerns
with including category-b in binary form, in the binary packages of
our releases:

http://www.apache.org/legal/resolved.html#category-b

Regards,

-Rob


> Pedro.
>
> PS. My proposal was a step in the right direction but
> given that it's already insufficient I hereby withdraw
> it.
>

Mime
View raw message