www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: Two weeks left for comments! (was: [Request For Comment] Third-Party Licensing Policy)
Date Thu, 30 Mar 2006 01:59:08 GMT
On Mar 29, 2006, at 12:56 PM, Cliff Schmidt wrote:
> On 3/29/06, Roy T. Fielding <fielding@gbiv.com> wrote:
>> On Mar 29, 2006, at 12:02 AM, Cliff Schmidt wrote:
>>> Here's how the applicable part of the policy reads in the current
>>> (v0.52) draft:
>>> (from http://people.apache.org/~cliffs/3party.html#options-build-
>>> mustnot1)
>>> "YOU MUST NOT distribute build scripts or documentation within an
>>> Apache product with the purpose of causing the default/standard  
>>> build
>>> of an Apache product to include any part of a prohibited work."
>>> Maybe this needs to be reworded a little.  Let me first say what  
>>> I was
>>> trying to accomplish with it.  I think it would be a bad idea for us
>>> to decide that on one hand we won't include GPL'd works within an
>>> Apache product, but then distribute a product that require static
>>> linking with a GPL'd work on the user's system to produce a standard
>>> binary.  In other words, standard product binaries, whether
>>> distributed by Apache or built on the user's machine should have the
>>> same applicable licenses.
>>> There's certainly nothing wrong with an Apache product dynamically
>>> using a GPL'd work as a system requirement, nor with the product
>>> depending on the presence of a Microsoft Windows operating system  
>>> or a
>>> Sun JVM.  The key is to not let the Apache product get confused with
>>> the system requirements it depends on.
>>> So, any thoughts on how to better word the requirement listed above?
>>> Does it help to talk about static linking with the prohibited  
>>> work or
>>> embedding the prohibited work inside the product?
>> I think you should remove it -- among other things, it places a
>> policy restriction on ourselves that is contrary to open source
>> principles.  Users of our software should be allowed to link with
>> anything in their environment.
> Absolutely agree; in fact, the policy even specifically says that
> there's nothing wrong with even providing options that make it easy
> for users to do this: see
> http://people.apache.org/~cliffs/3party.html#options-build-may1.
> The question is about what a PMC does to cause "the default/standard
> build" to statically link into a single executable, which would likely
> be perceived as being the executable form of the Apache product.

And my answer was to that question.  If an Apache project creates a
product whose purpose is to interface with a proprietary product, then
your policy document forbids the project from distributing the product
even when we have the legal right to do so.

For example, if Apache Jackrabbit were to create a set of tools to
help users of proprietary systems migrate from those systems to a
JCR repository, and the only way those tools can work is by compiling
them against a proprietary interface for data extraction, then the
policy prevents users from obtaining this functionality from Apache
because we can't even distribute the source to them.

My answer is: there are no restrictions on Apache projects to create
and distribute source code that, when compiled by the *user* on their
platform, may result in linking with a non-Apache product.  Likewise,
there is no restriction on Apache projects for creating (w/permission)
documentation that describes how to interface with proprietary systems.
Source code is documentation.

>> We should not be prohibited from
>> creating the bridge code between open source and proprietary systems,
>> provided that none of that code is distributed in our products.
> Absolutely agree -- see
> http://people.apache.org/~cliffs/3party.html#options-inproduct-may1.
>> For example, Maven would have to be gutted under that policy, and
>> all of our JSR-based projects would be terminated, including
>> Geronimo, JAMES, and Jackrabbit.
> I wasn't aware that any of these projects distribute
> source/object/class/build files that cause the standard default build
> to statically link or incorporate some piece of software on the user's
> machine into a single executable with the Apache product.

All of those projects require spec jars that are bound by specification
licenses which fall under the category of "forbidden" because they don't
meet the OSD.  They can't be built without those jars present.  Java's
dynamic binding does cause the names to be copied into the work and
the names are covered under the specification license.  The problem is
you wrote "to include any part of a prohibited work", which is far
more than copyright requires -- there is nothing wrong with copying
interface names from a prohibited work if there exists some argument
that the copyright holder intends the interface to be used.

In any case, as I've mentioned before, there is no reason to constrain
self-contained shell scripts to non-viral terms.  We simply do not care
if there exists a shell script covered by GPL within one of our products
because its presence does not add any further restrictions than what
would have existed if the script was under AL2.


DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message