You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Cliff Schmidt <cl...@apache.org> on 2006/03/14 02:49:40 UTC
[Request For Comment] Third-Party Licensing Policy
See http://people.apache.org/~cliffs/3party.html for a draft policy
regarding the use of third-party works in Apache products and their
various licenses. The policy includes license criteria, lists of
specifically authorized and excluded licenses, a license labeling
policy, options for works under excluded licenses, and a transition
policy.
Please send any comments, concerns, feedback, and flames to this
list, unless you have a special need to keep your comments private
(since this list has a publicly accessible archive).
Although this is an internal policy directed at Apache committers and
PMC members, it impacts how Apache products will be licensed, which
Apache users obviously have an interest in. Therefore, I'm also
interested in any feedback from a user's point of view.
Thanks,
Cliff Schmidt
Legal Affairs Officer
Apache Software Foundation
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 16, 2006, at 12:42 PM, Noel J. Bergman wrote:
>
> Then how does CDDL differ from some GPL + Binary Exception type
> license?
As I've said half a million times before, the GPL is written to
exclude exceptions. It says, point blank, that no exceptions are
allowed. One cannot construct a license that is internally
contradictory without asking the users to believe a lie, and thus
there is no such thing as a valid GPL + Binary Exception type license.
[The FSF's opinions on that matter are irrelevant because they do not
suffer if the exception is found to be invalid -- the GPL survives.]
A GPL-covered work can be dual-licensed, meaning the second license is
a complete copyright license that can stand on its own and not some
half-baked exception.
....Roy
---------------------------------------------------------------------
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
RE: [Request For Comment] Third-Party Licensing Policy
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin Erenkrantz wrote:
> Noel J. Bergman wrote:
> > Does this mean that if I were to download Apache Foo, make proprietary
> > changes to some of it, and distribute the binary packages as DevTech
Bar,
> > that I am required to distribute the source for Apache Foo? And what
about
> > my changes?
> Your changes to files present Apache Foo fall under the CDDL and must
> be distributed as source to all people who receive DevTech Bar.
Then how does CDDL differ from some GPL + Binary Exception type license?
--- Noel
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/16/06, Noel J. Bergman <no...@devtech.com> wrote:
> Does this mean that if I were to download Apache Foo, make proprietary
> changes to some of it, and distribute the binary packages as DevTech Bar,
> that I am required to distribute the source for Apache Foo? And what about
> my changes?
Your changes to files present Apache Foo fall under the CDDL and must
be distributed as source to all people who receive DevTech Bar. --
justin
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 17 March 2006 09:25, Roy T. Fielding wrote:
> Note,
> however, that the vast majority of our *users* are simply using Apache
> software in-house with no external distribution.
Hmmm... I disagree that this is relevant, and might even be harmful to the ASF
to have such 'attitude'... Let me elaborate;
First of all, 5% of 10million is still a lot of people...
But more importantly;
Companies are flocking around the open-source projects that are friendly to
their business. Software companies do so, just like other business. However,
John Doe's PizzaCorner running an Apache server (a user!) will never ever
contribute any developer back to ASF or open source for that matter. The
closer to the "we distribute software" end of the scale you go, the more
likely it is to see "paid for" resources being contributed into ASF projects.
Or other business friendly projects, like the Eclipse foundation.
By actively persuing the idea that we are Ok with imposing additional
restrictions (more than now) on Apache sources, may drive some of these
companies to re-consider their use of Apache sources, and with that drop
their employees from the contribution list.
My suggestion; Don't go there...
Cheers
Niclas
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 17, 2006, at 12:06 PM, Cliff Schmidt wrote:
> On 3/16/06, Roy T. Fielding <fi...@gbiv.com> wrote:
>> Well, yes, that is typical of commercial software companies. Note,
>> however, that the vast majority of our *users* are simply using
>> Apache
>> software in-house with no external distribution. They can modify
>> that
>> software to their heart's content because they have the open source.
>
> But, Roy, as you know, there are very few requirements of users (as
> you define them) in *any* open source license, including the GPL. The
> whole point here is determining what licenses are acceptable to those
> who do want to externally distribute our software. The Apache users
> who get their software directly from us and have no concern about ever
> needing to distribute it outside their organization should be fine
> with just about any open source license.
Yes, assuming they are given the source code that was used to build
the Apache product. That is our public, our mission is to serve *them*,
and redistributors that only redistribute binaries to their users are
not respecting that mission. That's okay by me, but it removes them
from consideration when we decide how best to accomplish the ASF
mission.
If we happen to have a policy that makes such redistributors happy,
that is a "nice to have", but under no circumstances has it ever been
a principle of the ASF, or the Apache Group for that matter. For us,
the Apache License is a tool that is used to accomplish our mission
within the bounds of legal precedence -- it does not define the mission
in and of itself.
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Cliff Schmidt <cl...@gmail.com>.
On 3/16/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Mar 16, 2006, at 4:51 PM, Will Glass-Husain wrote:
>
> > Wow, that's provocative. I've been lurking here, going to jump in.
> >
> > As a small business which develops commercial software that uses
> > Apache libraries, this discussion is critical. We use a number of
> > Apache libraries verbatim and one modified Apache library. My use
> > case involves redistribution of binaries (including one modified),
> > and (despite Roy's disclaimers) I think this is typical.
>
> Well, yes, that is typical of commercial software companies. Note,
> however, that the vast majority of our *users* are simply using Apache
> software in-house with no external distribution. They can modify that
> software to their heart's content because they have the open source.
But, Roy, as you know, there are very few requirements of users (as
you define them) in *any* open source license, including the GPL. The
whole point here is determining what licenses are acceptable to those
who do want to externally distribute our software. The Apache users
who get their software directly from us and have no concern about ever
needing to distribute it outside their organization should be fine
with just about any open source license.
Cliff
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 16, 2006, at 4:51 PM, Will Glass-Husain wrote:
> Wow, that's provocative. I've been lurking here, going to jump in.
>
> As a small business which develops commercial software that uses
> Apache libraries, this discussion is critical. We use a number of
> Apache libraries verbatim and one modified Apache library. My use
> case involves redistribution of binaries (including one modified),
> and (despite Roy's disclaimers) I think this is typical.
Well, yes, that is typical of commercial software companies. Note,
however, that the vast majority of our *users* are simply using Apache
software in-house with no external distribution. They can modify that
software to their heart's content because they have the open source.
> First - to Cliff's efforts - bravo! I'm strongly in favor of an
> "Apache Brand" that discourages reciprocity clauses. Note:
> discourages, not prohibits is the key. I want to download Apache
> stuff without thinking and worrying about lurking license clauses.
> If there's reciprocity I need it spelled out in big green text at
> the top of the page so that I can evaluate the the benefit of
> including it vs. the additional administrative burden.
>
> Second, to Roy's comments on CDDL vs. Apache. Agreed, CDDL sounds
> much less restrictive than LGPL in that it limits source
> redistribution requirements to file changes. If an Apache project
> was licensed under CDDL, I'd still use it. But it definitely
> represents an additional inconvenience for the occasional case in
> which I modify a library.
Absolutely. A good question to ask is how much effort is it, really, to
isolate your changes so that only "obvious public stuff", such as hooks
for extensibility where it was lacking before, are made to the CDDL
files?
Your proprietary additions would then be separate files, not covered by
CDDL, and only the obvious public stuff needs to be made available as
source code to your users.
> My point on CDDL is that it's a detriment to the user (admittedly
> somewhat minor) but still, I'm not seeing the benefits. Apache's
> liberal stance towards commercial use and redistribution is what
> attracted me as a user in the first place. While I didn't have to
> get involved, now I'm a committer.
The difference is that the user receives *our* work as open source,
which
they can modify (if needed) and potentially rebuild alongside your
proprietary work. That is a HUGE benefit to the user and to your
business
because then they do not lose any rights by obtaining our work from you
rather than obtaining it directly from apache.org.
> Why put up any roadblocks?
>
> Cliff-- feel free to yell at me for carrying on a possibly off-
> topic subject. But I want to emphasize that the "Apache Brand",
> however we define it, is what attracts a community. Let's not
> change it lightly.
It is actually on-topic, since the policy Cliff is working on will be
thrashed on quite a bit by the general public. It is handy for Cliff
to have sufficient justification and examples ready before that happens.
It also helps to be able to say that we considered other alternatives,
but decided to go this route because ...
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Will Glass-Husain <wg...@forio.com>.
Wow, that's provocative. I've been lurking here, going to jump in.
As a small business which develops commercial software that uses Apache
libraries, this discussion is critical. We use a number of Apache libraries
verbatim and one modified Apache library. My use case involves
redistribution of binaries (including one modified), and (despite Roy's
disclaimers) I think this is typical.
First - to Cliff's efforts - bravo! I'm strongly in favor of an "Apache
Brand" that discourages reciprocity clauses. Note: discourages, not
prohibits is the key. I want to download Apache stuff without thinking and
worrying about lurking license clauses. If there's reciprocity I need it
spelled out in big green text at the top of the page so that I can evaluate
the the benefit of including it vs. the additional administrative burden.
Second, to Roy's comments on CDDL vs. Apache. Agreed, CDDL sounds much less
restrictive than LGPL in that it limits source redistribution requirements
to file changes. If an Apache project was licensed under CDDL, I'd still
use it. But it definitely represents an additional inconvenience for the
occasional case in which I modify a library.
My point on CDDL is that it's a detriment to the user (admittedly somewhat
minor) but still, I'm not seeing the benefits. Apache's liberal stance
towards commercial use and redistribution is what attracted me as a user in
the first place. While I didn't have to get involved, now I'm a committer.
Why put up any roadblocks?
Cliff-- feel free to yell at me for carrying on a possibly off-topic
subject. But I want to emphasize that the "Apache Brand", however we define
it, is what attracts a community. Let's not change it lightly.
WILL
On 3/16/06, Roy T. Fielding <fi...@gbiv.com> wrote:
>
> On Mar 16, 2006, at 12:34 PM, Jim Jagielski wrote:
> > So, if I take an ASF product, say Apache Foo, and use that
> > as the basis of my commercial product, Jim Bar, and in the
> > process make improvements on Apache Foo, I am *required*
> > to make those improvements available?
>
> If you make improvements to the source code of CDDL Foo by
> modifying the files that were within CDDL Foo, and then distribute
> that as Jim Bar to a third party, then you also have to make
> available the modifications to CDDL Foo to that third party as
> CDDL source. There is nothing forcing you to make improvements
> within the files of the original CDDL Foo -- that is more likely
> an indication that the changes belong to the project anyway.
> There is also nothing forcing you to provide the source to
> anyone other than the third party given Jim Bar.
>
> > If so, then that is a major change to one of the
> > principles on which the ASF has been based. We would
> > *like* people to do that, but *forcing* them to do it
> > is something we've avoided, for many reasons. I think
> > the "you can use it however you want" simplicity
> > of the AL is one reason for the major success and
> > wide usage of Apache code.
>
> People can use CDDL source however they want, too. What you are
> saying is that a principle of the ASF is that we provide free source
> for closed companies to treat as if they wrote it themselves, with
> no further responsibility to the community or to their own users
> aside from the NOTICE file.
>
> I'd agree that such has been our policy in the past. I disagree
> that it has been useful for our users or beneficial to the public,
> and I am quite certain that our foundation's mission would be just
> as well served by CDDL as it is by AL2. Among other things, it
> encourages projects to emphasize modularity and extensibility in
> their designs.
>
> >> In my opinion, the ASF should allow its products to be distributed
> >> under either AL2 or CDDL. I don't give a rat's ass what people
> >> think about the "Apache brand" being associated with BSD-style code,
> >> since I don't consider the difference to be relevant to our users.
> >> CDDL is just as good, if not better, for open development.
> >>
> >
> > Wow. I would consider dual-licensing as a MAJOR change
> > for the ASF. And I submit that the "difference" *is* relevant
> > for many of our users..
>
> I didn't say dual-licensing. I said one or the other license,
> because both of them allow our projects to accomplish our mission.
>
> And it isn't the first time I've suggested major changes to the ASF.
>
> ....Roy
>
>
> ---------------------------------------------------------------------
> 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
>
>
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Henri Yandell <ba...@apache.org>.
On Thu, 16 Mar 2006, Roy T. Fielding wrote:
> People can use CDDL source however they want, too. What you are
> saying is that a principle of the ASF is that we provide free source
> for closed companies to treat as if they wrote it themselves, with
> no further responsibility to the community or to their own users
> aside from the NOTICE file.
>
> I'd agree that such has been our policy in the past. I disagree
> that it has been useful for our users or beneficial to the public,
> and I am quite certain that our foundation's mission would be just
> as well served by CDDL as it is by AL2. Among other things, it
> encourages projects to emphasize modularity and extensibility in
> their designs.
Sorry for cutting out a lot of context Roy, it's the paragraph above that
woke me up and made me want to reply.
The discussion going on is very interesting, and I'm definitely not
against MPL/CDDL - some of the bits that have been explained to me sound
very attractive for the next ASL license, but the important goal of
Cliff's policy is not to dictate a new ASF policy for the future - it's to
try and coalesce the current loose ASF policy into something we can
actually rely on.
Given that most of us committers are still stumbling blindly along with
what each of the licenses means, the foundation needs to define something
so that committers can get on with coding - it's why the foundation exists
after all [hopefully that isn't too bombastic a suggestion :) ].
Cliff's current policy seems to do well here. It has a "yes" area, it has
a "no" area and it has a grey area in the middle of which it has drawn a
line. Thankfully that line isn't of much pain to the ASF, the Java part of
the ASF can quite happily ship binaries and point to source urls and as
those libraries are mostly popular in the Java space I'm not sure it
affects other parts of the ASF that much in the short to medium term.
In fact I wouldn't be surprised to discover that projects are shipping the
binaries and pointing to source already, instead of shipping the source;
but that's not something I've looked into that much.
Given that your disagreement is that we should be shipping the source
too(??), it doesn't seem like a major issue that would be blocking the
acceptance of the current policy. Rather it seems to be a discussion for
the next 6 months in the formulation of changes to the policy based on
lessons learned or new ideas.
> And it isn't the first time I've suggested major changes to the ASF.
Without people suggesting changes the ASF will stagnate. I don't know the
history as well as most of you do, but I'm pretty sure we need to continue
to adapt.
Hen
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 16, 2006, at 12:34 PM, Jim Jagielski wrote:
> So, if I take an ASF product, say Apache Foo, and use that
> as the basis of my commercial product, Jim Bar, and in the
> process make improvements on Apache Foo, I am *required*
> to make those improvements available?
If you make improvements to the source code of CDDL Foo by
modifying the files that were within CDDL Foo, and then distribute
that as Jim Bar to a third party, then you also have to make
available the modifications to CDDL Foo to that third party as
CDDL source. There is nothing forcing you to make improvements
within the files of the original CDDL Foo -- that is more likely
an indication that the changes belong to the project anyway.
There is also nothing forcing you to provide the source to
anyone other than the third party given Jim Bar.
> If so, then that is a major change to one of the
> principles on which the ASF has been based. We would
> *like* people to do that, but *forcing* them to do it
> is something we've avoided, for many reasons. I think
> the "you can use it however you want" simplicity
> of the AL is one reason for the major success and
> wide usage of Apache code.
People can use CDDL source however they want, too. What you are
saying is that a principle of the ASF is that we provide free source
for closed companies to treat as if they wrote it themselves, with
no further responsibility to the community or to their own users
aside from the NOTICE file.
I'd agree that such has been our policy in the past. I disagree
that it has been useful for our users or beneficial to the public,
and I am quite certain that our foundation's mission would be just
as well served by CDDL as it is by AL2. Among other things, it
encourages projects to emphasize modularity and extensibility in
their designs.
>> In my opinion, the ASF should allow its products to be distributed
>> under either AL2 or CDDL. I don't give a rat's ass what people
>> think about the "Apache brand" being associated with BSD-style code,
>> since I don't consider the difference to be relevant to our users.
>> CDDL is just as good, if not better, for open development.
>>
>
> Wow. I would consider dual-licensing as a MAJOR change
> for the ASF. And I submit that the "difference" *is* relevant
> for many of our users..
I didn't say dual-licensing. I said one or the other license,
because both of them allow our projects to accomplish our mission.
And it isn't the first time I've suggested major changes to the ASF.
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Jim Jagielski <ji...@jaguNET.com>.
I like analogies; I think that they can be very useful
to illustrate points, but looking at them from a different
angle.
Anyway, there are a bunch of people with the goal to make money
in a safe but efficient way. A bunch of us get together and, with
that goal in mind, come up with a plan to do so. One major
aspect of the plan is the reliance on careful investment in
real estate. Not stocks. Not collectables. Real Estate.
We are successful, have a good track record, and people
are drawn to us because of what we do and what
we represent.
The one day someone says "You know, we would do better
by investing in orange juice futures. We would make
a killing and, after all, that's closer to
our goal of making more money than anything else!"
Even ignoring the major question on whether or
not the change would result in the claims actually
happening, there is also the question on whether
it actually meets the criteria of the goal itself.
Furthermore, many, MANY people who use the Apache
Investment Foundation are doing so *because*
we invent in real estate. If they want to invest
in gold or orange juice or stocks or whatever, they
would have chosen a different entity. In other
words, what's important is the totality of what we
are and what we represent, not just a single aspect
of that. It's not tail wagging dog or anything like
that. Would we be the same foundation if, all of a
sudden we said that consensus-based collaboration is
more trouble that it's worth, and doesn't help achieve
the result we want and therefore we're dropping it?
There's nothing in wanting to "produce open source that
is usable by as many people as possible" that requires
our method. It's just that we have built ourselves
around that as a guiding principle.
Anyway, those are my thoughts. No doubt there are
holes in my interpretation which will quickly be
exposed :)
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Cliff Schmidt <cl...@gmail.com>.
On 3/16/06, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Mar 16, 2006, at 2:30 PM, Roy T. Fielding wrote:
>
> > MPL 1.1 was specifically designed to only apply
> > reciprocal terms to changes within the covered work, and CDDL improves
> > on that to make the executable forms distributable under any license
> > provided that the covered code is also distributed (separately) as
> > source code.
> >
> > Thus, we can use CDDL within trade secret applications, assuming that
> > the secret part isn't already in the CDDL covered code
> > (which can be assumed because it is supposed to be secret).
> >
> > As a result, I think CDDL does a better job of preserving "Apache
> > principles" than our own license.
>
> So, if I take an ASF product, say Apache Foo, and use that
> as the basis of my commercial product, Jim Bar, and in the
> process make improvements on Apache Foo, I am *required*
> to make those improvements available?
>
> If so, then that is a major change to one of the
> principles on which the ASF has been based. We would
> *like* people to do that, but *forcing* them to do it
> is something we've avoided, for many reasons. I think
> the "you can use it however you want" simplicity
> of the AL is one reason for the major success and
> wide usage of Apache code.
+1
> > In my opinion, the ASF should allow its products to be distributed
> > under either AL2 or CDDL. I don't give a rat's ass what people
> > think about the "Apache brand" being associated with BSD-style code,
> > since I don't consider the difference to be relevant to our users.
> > CDDL is just as good, if not better, for open development.
> >
>
> Wow. I would consider dual-licensing as a MAJOR change
> for the ASF. And I submit that the "difference" *is* relevant
> for many of our users..
+1
> Sounds like a good idea for *another* foundation to
> spring up about. :)
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 16, 2006, at 2:30 PM, Roy T. Fielding wrote:
> MPL 1.1 was specifically designed to only apply
> reciprocal terms to changes within the covered work, and CDDL improves
> on that to make the executable forms distributable under any license
> provided that the covered code is also distributed (separately) as
> source code.
>
> Thus, we can use CDDL within trade secret applications, assuming that
> the secret part isn't already in the CDDL covered code
> (which can be assumed because it is supposed to be secret).
>
> As a result, I think CDDL does a better job of preserving "Apache
> principles" than our own license.
So, if I take an ASF product, say Apache Foo, and use that
as the basis of my commercial product, Jim Bar, and in the
process make improvements on Apache Foo, I am *required*
to make those improvements available?
If so, then that is a major change to one of the
principles on which the ASF has been based. We would
*like* people to do that, but *forcing* them to do it
is something we've avoided, for many reasons. I think
the "you can use it however you want" simplicity
of the AL is one reason for the major success and
wide usage of Apache code.
>
> In my opinion, the ASF should allow its products to be distributed
> under either AL2 or CDDL. I don't give a rat's ass what people
> think about the "Apache brand" being associated with BSD-style code,
> since I don't consider the difference to be relevant to our users.
> CDDL is just as good, if not better, for open development.
>
Wow. I would consider dual-licensing as a MAJOR change
for the ASF. And I submit that the "difference" *is* relevant
for many of our users..
Sounds like a good idea for *another* foundation to
spring up about. :)
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-03-17 at 16:38 -0600, William A. Rowe, Jr. wrote:
> Some of us in the ASF, from the BSD crowd to users like myself from a Windows
> background, always percieved this as a principle, even if it's a second tier
> priciple behind community and collaborative code.
>
> If we percieved differently, we wouldn't be here, we would be elsewhere in the
> GNU umbrella or elsewhere. We wouldn't have fought to create a portability
> runtime under the ASL, because there is the NSPR and other code to do that.
> We (speaking for myself and some unquantified subset of the developers) built
> APR precisely so it could be used anywhere.
>
> APR serves no 'users', it serves developers who build software on top of it.
> I think the entire 'we serve users' is sort of silly, as you keep qualifying it
> with 'end users'. When working in APR-space, end-users are the furthest thing
> from my mind, they shouldn't even be aware of 'some library' when httpd, svn
> and other consuming projects do their job right in configuration, detection and
> packaging :)
Big +1 from me .. the fact that ASF produces software under the Apache
License is effectively a principle for me as most of what I do in ASF is
far from end users too.
Cliff I will give my feedback next week.
Sanjiva.
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 17, 2006, at 2:38 PM, William A. Rowe, Jr. wrote:
> Some of us in the ASF, from the BSD crowd to users like myself from
> a Windows
> background, always percieved this as a principle, even if it's a
> second tier
> priciple behind community and collaborative code.
>
> If we percieved differently, we wouldn't be here, we would be
> elsewhere in the
> GNU umbrella or elsewhere. We wouldn't have fought to create a
> portability
> runtime under the ASL, because there is the NSPR and other code to
> do that.
> We (speaking for myself and some unquantified subset of the
> developers) built
> APR precisely so it could be used anywhere.
I understand why you might have gotten that impression, but it is
historically inaccurate. Please look at the apache-nspr module under
our old cvs (still at /home/cvs/apache-nspr but I think it is scheduled
to move to archive at some point). You might also want to look at the
new-httpd and apache-core (now httpd-pmc) archives as well. There are
hundreds of emails on the topic from April 1998 through April 1999.
NSPR was going to be used for Apache 2. We even had a prototype that
Dean put a lot of work into. We had to scrap it because, and ONLY
because, the patent clause in MPL 1.0 was unacceptable to the group.
There was a great deal of discussion among myself, Brian, and Mitchell
about using NSPR and fixing the patent clause in MPL 1.0 (e.g. 11/98).
However, we didn't adopt NSPR in the end simply because it took Mozilla
too long to approve MPL 1.1 and apply it to NSPR (see discussion
of April 20, 1999, on apache-core). Bill Stoddard had started a group at
IBM to work on APPR on November 30, 1998. By the time NSPR was MPL 1.1,
the group at IBM had invested so much effort into APPR (renamed APR),
even though it was barely functional at the time, that going back
to an NSPR base was socially impossible.
At no time whatsoever, during that entire year plus conversation,
did any of the Apache core folks say that the MPL's version of copyleft
was somehow "against our principles." We all read the license. We all
knew how to read licenses. Jim sure as heck didn't think so at the
time.
Any claim that use of MPL (or its even more liberal child CDDL) is
"against Apache principles" is absolute rubbish. It may be against your
principles, but that doesn't make them Apache.
Once again, this conversation has burned me out when I should have been
helping real projects achieve real releases. The next person who wants
to spout off about what it means to be at Apache had better damn well
do their homework.
> APR serves no 'users', it serves developers who build software on
> top of it.
Huh. Maybe that explains APR's design decisions.
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
>
> Saying something is a principle is equivalent to saying that it
> cannot be changed, that it is inherent, or that any discussion
> of the point is moot. If you are going to use it, then at least
> add a preamble saying that "Here are some constraints laid down by
> the ASF Board of Directors that apply to all ASF projects. We will
> treat these constraints as the guiding principles of this policy;
> if the constraints are changed by later act of the Board, this
> policy will have to be revised accordingly."
Some of us in the ASF, from the BSD crowd to users like myself from a Windows
background, always percieved this as a principle, even if it's a second tier
priciple behind community and collaborative code.
If we percieved differently, we wouldn't be here, we would be elsewhere in the
GNU umbrella or elsewhere. We wouldn't have fought to create a portability
runtime under the ASL, because there is the NSPR and other code to do that.
We (speaking for myself and some unquantified subset of the developers) built
APR precisely so it could be used anywhere.
APR serves no 'users', it serves developers who build software on top of it.
I think the entire 'we serve users' is sort of silly, as you keep qualifying it
with 'end users'. When working in APR-space, end-users are the furthest thing
from my mind, they shouldn't even be aware of 'some library' when httpd, svn
and other consuming projects do their job right in configuration, detection and
packaging :)
Bill
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 17, 2006, at 1:50 PM, Cliff Schmidt wrote:
> Well, if the board ever decides to loosen the restriction to allow two
> or three options for Apache projects to license their work under, I
> will revise the third-party licensing policy's principle to say
> something like, "The ASF must be able to distribute works created
> within an Apache Project solely under one of the board-approved
> licenses for Apache project works." This would still address the
> concern I have that we don't use licenses in third-party works that
> would restrict our ability to license works created in projects within
> whatever the board-constrained licenses are.
>
> But until that day, I think the principle is fine the way it is. I'm
> not asking for a discussion about whether the ASF should change how
> project-created works are licensed. This is a discussion about a
> policy for inclusion of *third-party works*.
Well, right now it is documentation, and generally it is preferred
for our documentation to use correct English. You need to look up
the definition of "principle" and see why that doesn't make any sense,
and why I am arguing with you about such a tiny thing like the
central topic of my dissertation (principled design), because until you
fix it there will be a lot of pointless cross-chatter due to what is
written not matching what you intend. As is shown by Merriam-Webster:
Main Entry: principle
Function: noun
1 a : a comprehensive and fundamental law, doctrine, or assumption
b (1) : a rule or code of conduct
(2) : habitual devotion to right principles <a man of principle>
c : the laws or facts of nature underlying the working of an
artificial device
2 : a primary source : ORIGIN
3 a : an underlying faculty or endowment <such principles of human
nature as greed and curiosity>
b : an ingredient (as a chemical) that exhibits or imparts a
characteristic quality
4 capitalized, Christian Science : a divine principle : GOD
Main Entry: constraint
Function: noun
1 a : the act of constraining
b : the state of being checked, restricted, or compelled to avoid
or perform some action <the constraint and monotony of a
monastic life -- Matthew Arnold>
c : a constraining condition, agency, or force : CHECK
<put legal constraints on the board's activities>
2 a : repression of one's own feelings, behavior, or actions
b : a sense of being constrained : EMBARRASSMENT
Saying something is a principle is equivalent to saying that it
cannot be changed, that it is inherent, or that any discussion
of the point is moot. If you are going to use it, then at least
add a preamble saying that "Here are some constraints laid down by
the ASF Board of Directors that apply to all ASF projects. We will
treat these constraints as the guiding principles of this policy;
if the constraints are changed by later act of the Board, this
policy will have to be revised accordingly."
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Cliff Schmidt <cl...@gmail.com>.
On 3/17/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Mar 17, 2006, at 11:56 AM, Cliff Schmidt wrote:
> > On 3/16/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> >> On Mar 16, 2006, at 1:31 PM, Cliff Schmidt wrote:
> >>
> >>> After looking at your latest post, I actually think we are on the
> >>> same
> >>> page on all but the binary question for reciprocal licenses. Let me
> >>> know if I'm misconstruing your comments below, but it looks like you
> >>> have affirmed the three license criteria of the policy, but disagree
> >>> on the extra condition for reciprocal licenses.
> >>
> >> And I don't agree with the first two "Guiding Principles", as I
> >> already pointed out.
> >
> > Actually, no. it's only the second principle you disagree with. You
> > previously misread the first principle, and I even chose to revise it
> > with your words to be *extra* clear. As a reminder:
>
> Cliff, I haven't gone senile yet. I don't agree with the principle
> that ASF projects must only produce software under the Apache License.
> The only principle that exists is the one written in our incorporation
> agreement with the state, which is that we produce open source software
> for the public.
Sorry about that, Roy. Of course, it's dangerous to try to tell
someone what they disagree with. I just thought we had resolved that
issue, but now I understand what your concern is. So, I guess this
remains an issue we will have to agree to disagree on.
> The board has constrained the projects to produce new software under
> the Apache License. That is a constraint, not a principle. At times
> I have agreed with that constraint, at other times I have disagreed
> with it, and right now I would prefer that the board only constrain
> us to licenses that accomplish our mission. In any case, I want to
> make it clear that there are some policies that are inherent in our
> Foundation and others that are simply choices that we have made.
Well, if the board ever decides to loosen the restriction to allow two
or three options for Apache projects to license their work under, I
will revise the third-party licensing policy's principle to say
something like, "The ASF must be able to distribute works created
within an Apache Project solely under one of the board-approved
licenses for Apache project works." This would still address the
concern I have that we don't use licenses in third-party works that
would restrict our ability to license works created in projects within
whatever the board-constrained licenses are.
But until that day, I think the principle is fine the way it is. I'm
not asking for a discussion about whether the ASF should change how
project-created works are licensed. This is a discussion about a
policy for inclusion of *third-party works*.
Cliff
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 17, 2006, at 11:56 AM, Cliff Schmidt wrote:
> On 3/16/06, Roy T. Fielding <fi...@gbiv.com> wrote:
>> On Mar 16, 2006, at 1:31 PM, Cliff Schmidt wrote:
>>
>>> After looking at your latest post, I actually think we are on the
>>> same
>>> page on all but the binary question for reciprocal licenses. Let me
>>> know if I'm misconstruing your comments below, but it looks like you
>>> have affirmed the three license criteria of the policy, but disagree
>>> on the extra condition for reciprocal licenses.
>>
>> And I don't agree with the first two "Guiding Principles", as I
>> already pointed out.
>
> Actually, no. it's only the second principle you disagree with. You
> previously misread the first principle, and I even chose to revise it
> with your words to be *extra* clear. As a reminder:
Cliff, I haven't gone senile yet. I don't agree with the principle
that ASF projects must only produce software under the Apache License.
The only principle that exists is the one written in our incorporation
agreement with the state, which is that we produce open source software
for the public.
The board has constrained the projects to produce new software under
the Apache License. That is a constraint, not a principle. At times
I have agreed with that constraint, at other times I have disagreed
with it, and right now I would prefer that the board only constrain
us to licenses that accomplish our mission. In any case, I want to
make it clear that there are some policies that are inherent in our
Foundation and others that are simply choices that we have made.
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Cliff Schmidt <cl...@gmail.com>.
On 3/16/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Mar 16, 2006, at 1:31 PM, Cliff Schmidt wrote:
>
> > After looking at your latest post, I actually think we are on the same
> > page on all but the binary question for reciprocal licenses. Let me
> > know if I'm misconstruing your comments below, but it looks like you
> > have affirmed the three license criteria of the policy, but disagree
> > on the extra condition for reciprocal licenses.
>
> And I don't agree with the first two "Guiding Principles", as I
> already pointed out.
Actually, no. it's only the second principle you disagree with. You
previously misread the first principle, and I even chose to revise it
with your words to be *extra* clear. As a reminder:
<reminder>
On 3/15/06, Cliff Schmidt <cl...@gmail.com> wrote:
> On 3/15/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> > Yes, you are right that I did not notice the emphasis on "created by".
> > It should actually say "created within an Apache Project" since
> > community has no distinct boundaries.
>
> done -- I actually rev'd the doc to 0.52 with just that change so this
> isn't unclear to anyone else.
> http://people.apache.org/~cliffs/3party.html#principle1
</reminder>
> What I decribed is how MPL and CDDL both meet
> all of the criteria aside from the first two "Guiding principles"
> (which are just criteria by a different name) and the extra condition
> on reciprocal licenses (another criteria by a different name).
No -- the guiding principles of the policy establish what the rest of
the document should be trying to achieve. It's not surprising that
your dissent with the second principle would coincide with your
disagreement with a part of the policy that implements the principle
(the license criteria condition on reciprocal licenses).
> It would make it a lot easier to read and discuss the policy if
> you simply list all of them as policy constraints, not principles
> and criteria and conditions. Every one of those items are policy
> decisions that could be changed by the board at any time (even
> reliance on the OSD to define what open source means -- the board
> could choose to write its own definition if it wanted to waste time).
Thanks for the feedback. If I hear others are having trouble with the
policy in its current approach, I will certainly consider
restructuring it.
Cliff
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 16, 2006, at 1:31 PM, Cliff Schmidt wrote:
> After looking at your latest post, I actually think we are on the same
> page on all but the binary question for reciprocal licenses. Let me
> know if I'm misconstruing your comments below, but it looks like you
> have affirmed the three license criteria of the policy, but disagree
> on the extra condition for reciprocal licenses.
And I don't agree with the first two "Guiding Principles", as I
already pointed out. What I decribed is how MPL and CDDL both meet
all of the criteria aside from the first two "Guiding principles"
(which are just criteria by a different name) and the extra condition
on reciprocal licenses (another criteria by a different name).
It would make it a lot easier to read and discuss the policy if
you simply list all of them as policy constraints, not principles
and criteria and conditions. Every one of those items are policy
decisions that could be changed by the board at any time (even
reliance on the OSD to define what open source means -- the board
could choose to write its own definition if it wanted to waste time).
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Cliff Schmidt <cl...@gmail.com>.
Roy,
After looking at your latest post, I actually think we are on the same
page on all but the binary question for reciprocal licenses. Let me
know if I'm misconstruing your comments below, but it looks like you
have affirmed the three license criteria of the policy, but disagree
on the extra condition for reciprocal licenses.
I'm pointing this out, because it is my responsibility to issue a
third-party licensing policy that makes sense for the ASF. At this
point, your comments are the only outstanding criticisms of the
policy, so I want to make sure it is as well defined as possible.
See below...
On 3/16/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> Copyleft is not just GPL -- it is the notion of reciprocal terms in
> general. GPL is contrary to our principles because it forces others
> to change the terms on their work just because it is combined with
> a work under GPL.
Sounds like support for http://people.apache.org/~cliffs/3party.html#criterion2:
"The license must not place restrictions on the distribution of
independent works that simply use or contain the covered work."
----
> MPL 1.1 was specifically designed to only apply
> reciprocal terms to changes within the covered work, and CDDL improves
> on that to make the executable forms distributable under any license
> provided that the covered code is also distributed (separately) as
> source code.
...
> I particularly like the fact that the CDDL
> defines that the source code form remains under CDDL even if the
> executable forms are sublicensed. That allows big companies to
> preserve their master contracts with customers, while at the same
> time preserving our own code as open source.
Sounds like support for http://people.apache.org/~cliffs/3party.html#criterion3:
"The license must not place restrictions on the distribution of larger
works, other than to require that the covered component still complies
with the conditions of its license."
----
and from an earlier post in this thread:
> it really has been the intention of the Foundation from its very
> beginning to be a distributor of open source.
and that would cover http://people.apache.org/~cliffs/3party.html#criterion1:
"The license must meet the Open Source Definition."
-----
So, would you agree that your only concern about the current version
of the policy is the condition for inclusion of reciprocally licensed
works? (http://people.apache.org/~cliffs/3party.html#criterion-reciprocity)
Cliff
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 16, 2006, at 11:56 AM, Noel J. Bergman wrote:
>> MPL 1.1 was specifically designed to only apply reciprocal
>> terms to changes within the covered work, and CDDL improves
>> on that to make the executable forms distributable under any
>> license provided that the covered code is also distributed
>> (separately) as source code.
>
>> Thus, we can use CDDL within trade secret applications,
>> assuming that the secret part isn't already in the CDDL
>> covered code
>
> Does this mean that if I were to download Apache Foo, make proprietary
> changes to some of it, and distribute the binary packages as
> DevTech Bar,
> that I am required to distribute the source for Apache Foo? And
> what about
> my changes?
As the license says, if you make changes to the source files covered
by CDDL then the source files that are changed remain under CDDL, and
anything in the source that is CDDL must be made available as source
to the same people who receive the binaries. This only applies to
modifications that are distributed to a third party.
> So continuing the above scenario, if I have a license under which I am
> willing to provide the source code for DevTech Bar to a customer,
> are you
> saying that my proprietarily changed source code should be perforce
> licensed
> under the Open Source license, forcibly open sourcing my proprietary
> changes?
No. It is difficult to create a new copyrightable work by making
changes that are entirely within the files of the existing copyrighted
work. Most people don't realize that such changes are rarely
copyrightable, and thus not proprietary at all. It is far better to
encourage people to do proprietary additions in separate files that
are not covered code, for the same reason that we encourage people
to build modular architectures.
In any case, source need only be made available to those who receive
the executables.
....Roy
---------------------------------------------------------------------
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
RE: [Request For Comment] Third-Party Licensing Policy
Posted by "Noel J. Bergman" <no...@devtech.com>.
Roy,
> MPL 1.1 was specifically designed to only apply reciprocal
> terms to changes within the covered work, and CDDL improves
> on that to make the executable forms distributable under any
> license provided that the covered code is also distributed
> (separately) as source code.
> Thus, we can use CDDL within trade secret applications,
> assuming that the secret part isn't already in the CDDL
> covered code
Does this mean that if I were to download Apache Foo, make proprietary
changes to some of it, and distribute the binary packages as DevTech Bar,
that I am required to distribute the source for Apache Foo? And what about
my changes?
> As a result, I think CDDL does a better job of preserving "Apache
> principles" than our own license.
> I particularly like the fact that the CDDL defines that the
> source code form remains under CDDL even if the executable
> forms are sublicensed.
So continuing the above scenario, if I have a license under which I am
willing to provide the source code for DevTech Bar to a customer, are you
saying that my proprietarily changed source code should be perforce licensed
under the Open Source license, forcibly open sourcing my proprietary
changes?
Keep in mind that this is the first sentence that doesn't end in a question
mark. :-)
--- Noel
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 15, 2006, at 1:34 PM, William A. Rowe, Jr. wrote:
> Jim Jagielski wrote:
>> On Mar 15, 2006, at 1:05 PM, Roy T. Fielding wrote:
>>> The license we use to do that changes over time.
>> "changes"? Refines, yes. But are you suggesting that
>> a "change" to a GPL-type license would be acceptable?
>> I don't. There are some ground-rules.
>
> LOL - I was thinking the same thing reading the first-post, has Roy
> been smoking some copyleft leaves? I trust - no :) Within the
> general
> spirit of the ASL language, some things I expect should -not- change
> over time.
Heh, no, but keep in mind that I've been working with these licenses
for years now and am frequently involved in the process of creating
them.
http://www.mozilla.org/MPL/MPL-1.1.html
http://www.sun.com/cddl/cddl.html
Copyleft is not just GPL -- it is the notion of reciprocal terms in
general. GPL is contrary to our principles because it forces others
to change the terms on their work just because it is combined with
a work under GPL. MPL 1.1 was specifically designed to only apply
reciprocal terms to changes within the covered work, and CDDL improves
on that to make the executable forms distributable under any license
provided that the covered code is also distributed (separately) as
source code.
Thus, we can use CDDL within trade secret applications, assuming that
the secret part isn't already in the CDDL covered code
(which can be assumed because it is supposed to be secret).
As a result, I think CDDL does a better job of preserving "Apache
principles" than our own license. MPL has a problem in that it is
too complicated for non-lawyers to understand. CDDL improved on
that significantly. I particularly like the fact that the CDDL
defines that the source code form remains under CDDL even if the
executable forms are sublicensed. That allows big companies to
preserve their master contracts with customers, while at the same
time preserving our own code as open source.
In fact, the only problem I know of with CDDL for open source is
that, like most licenses, it isn't GPL-compatible. I don't believe
that is even relevant now, since the only way to become GPL compatible
is to (dual-)license under GPL. The only reason the FSF claims that
MIT/BSD licensed code is "compatible" with GPL is because those
licenses allow the dual-license to be applied automatically.
The Apache License 2.0, in contrast, has a number of problems due
to my misguided attempts to make it GPL-compatible and too much leeway
given to relicense derivative works. However, it also influenced the
wording in CDDL, so most of what we were looking for in a 2.0 license
can be found in CDDL. The only way I can improve on AL2 is to remove
the sections on contributions/patent and formalize the now-standard
practice of requiring contributor agreements, reducing our distribution
license back to a BSD-style license plus NOTICE retention.
In my opinion, the ASF should allow its products to be distributed
under either AL2 or CDDL. I don't give a rat's ass what people
think about the "Apache brand" being associated with BSD-style code,
since I don't consider the difference to be relevant to our users.
CDDL is just as good, if not better, for open development.
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
>
> On Mar 15, 2006, at 1:05 PM, Roy T. Fielding wrote:
>
>> The license we use to do that changes over time.
>
> "changes"? Refines, yes. But are you suggesting that
> a "change" to a GPL-type license would be acceptable?
> I don't. There are some ground-rules.
LOL - I was thinking the same thing reading the first-post, has Roy
been smoking some copyleft leaves? I trust - no :) Within the general
spirit of the ASL language, some things I expect should -not- change
over time.
>> The additional restrictions
>> that the first two add do not adversely impact any of our users.
>
> Which, as I mentioned, I am not, and we should not,
> be concerned about *UNLESS* it affects redistribution which
> prevents it from being usable by everyone.
+1. Let me come back to the revenue systems I described elsewhere. This
probably falls into Roy's blanket 'insignificant portion' - users who wish
to use the code in truly trade-secret applications. The copyleft advocate
would add it's not only insignificant, but leaching technologies.
That doesn't mean that such applications -can't- return value to the OSS
communities! Of course they may. How many vanilla database / barcode /
mag encoding algorithms go into such applications? Given the choice, not
only does it make sense to use OSS for the components, but to feed the bug
fixes and enhancements back to the community. What breaks the model are
viral licenses, where the aggregated revenue document imaging systems are
very tightly guarded. The identifing micr/barcode/magstripe elements must
follow well defined standards; internal fraud detection elements remain
closely held secrets.
That was my industry; I'm sure some folks in other industries can offer
cases where viral licenses harm their use of OSS. If you suggest that
commercial applications as a whole our are 'insignificant portion', then
you reduce ASL code/ASF projects to only the hobbiest and GNU license
redistributors.
>> Beyond that, I don't agree with the theory that Apache products can't
>> be dependent on third-party code under some other license.
>
> The concern I and others have is hard-dependency. If the Apache
> product is worthless without the 3rd party code, then the
> code should be AL-compatible.
s/should/must/. ASL code on a non-viral-copyleft environment such as BSD
_MUST_ be useable without adding viral dependences, or it should find a more
appropriate home elsewhere. Keyword throughout the thread is 'compatible',
and I read it as 'equally or less restrictive' and 'non-viral'. Certain
additional restrictions pose no hardship (advertising clause? fine, if it's
documented in NOTICE.) Certain additional restrictions (upon 'this code and
all it's derivative code' or some such) offer hardships incompatible with the
ASL.
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Jim Jagielski <ji...@jagunet.com>.
On Mar 15, 2006, at 1:05 PM, Roy T. Fielding wrote:
>
>> Anything that dilutes that goal should
>> be actively avoided.
>
> No. Our goal is to distribute open source that is usable by everyone.
Just as I said. And we help accomplish that via our
selection and detailing of the License.
> The license we use to do that changes over time.
"changes"? Refines, yes. But are you suggesting that
a "change" to a GPL-type license would be acceptable?
I don't. There are some ground-rules.
> The additional restrictions
> that the first two add do not adversely impact any of our users.
Which, as I mentioned, I am not, and we should not,
be concerned about *UNLESS* it affects redistribution which
prevents it from being usable by everyone.
>
> Beyond that, I don't agree with the theory that Apache products can't
> be dependent on third-party code under some other license.
The concern I and others have is hard-dependency. If the Apache
product is worthless without the 3rd party code, then the
code should be AL-compatible.
> I don't
> see any harm in Apache producing the best interconnection software
> between, for example, Java and Oracle 10i, both of which are
> proprietary
> systems with incompatible licenses. That doesn't mean I think we
> should be redistributing Java or Oracle 10i, but it does mean we need
> to have flexibility in precisely defining license conditions according
> to the leeway we have with the interface.
+1
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/15/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> Yes, but now look at the licenses under that category. CDDL and
> MPL 1.1 are "usable and distributable as widely and as freely as
> possible". So is NPL, for that matter. The additional restrictions
> that the first two add do not adversely impact any of our users.
> In fact, I wouldn't be opposed to using something like CDDL, with
> file-based derivation clearly defined, for our own Apache software,
> since there are definite advantages to our users to have a clear
> separation line between what is Apache and what is their own. The
> only reason I didn't do that for AL2 is because I had a false hope
> of compatibility with GPL.
Switching to CDDL means that any changes to ASF code must fall under
CDDL (Section 3.2 of CDDL). That's a major policy change and one I'm
not sure I would support. -- justin
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 3/15/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> The goal should be to use
> the Apache License, but when that isn't possible there should be nothing
> in our policies to prevent one of our projects from creating a BSD
> or public domain or CDDL-covered file when doing so is necessary for
> the greater good.
Note that this isn't just a theoretical thing. Colm posted on this
list in the past about our "APR Examples" code, which we'd like to be
able to distribute as public domain so as to be absolutely clear that
it's ok for people to take our "hello world" (or "hello network
client", or whatever) and use it to build their own APR based
application. We've never really gotten a clear answer on the question
of "can we do that?"
-garrett
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 15, 2006, at 5:34 AM, Jim Jagielski wrote:
> On Mar 15, 2006, at 12:06 AM, Roy T. Fielding wrote:
>
>>
>> I do not know of ANY such users. Users do not care at all because
>> none of those licenses differ for a normal user (they only differ in
>> the terms for redistribution, not use). The only people who care are
>> the lawyers for large redistributors like IBM and BEA, and for them
>> it is simply a matter of convenience. I don't consider them to be a
>> significant portion of our users.
>>
>
> But *their* users are.
still an insignificant portion of our users. The tail should not be
wagging the dog.
>> They both state the same principle of license uniformity that has
>> never been true for the Apache HTTP Server Project (and thus never
>> for the ASF as a whole). I flatly disagree that the ASF has ever had
>> anything like that as a guiding principle. The board may have passed
>> a resolution last year to *add* that as a goal, but I know for a fact
>> that it hasn't been implemented in the projects because it can't be
>> without ripping out our build systems.
>
> I must not be understanding the above. We license stuff under
> the AL because that is how we want the code licensed, released
> and distributed.
That is how we want the stuff we create to be licensed.
> Anything that dilutes that goal should
> be actively avoided.
No. Our goal is to distribute open source that is usable by everyone.
The license we use to do that changes over time.
> If a ASF project is licensed under the
> AL and requires an external s/w package that is NOT licensed
> under the AL but the combined work has no more restrictions
> that a solely AL licensed work does (eg: AL + BSD) then
> we are OK with that. If, instead, the AL is subservient to
> the other license, then we have destroyed what it is
> we are trying to create: code usable and distributable as
> widely and as freely as possible. Otherwise, the 'Why Apache
> Software is Free' section is bogus.
Yes, but now look at the licenses under that category. CDDL and
MPL 1.1 are "usable and distributable as widely and as freely as
possible". So is NPL, for that matter. The additional restrictions
that the first two add do not adversely impact any of our users.
In fact, I wouldn't be opposed to using something like CDDL, with
file-based derivation clearly defined, for our own Apache software,
since there are definite advantages to our users to have a clear
separation line between what is Apache and what is their own. The
only reason I didn't do that for AL2 is because I had a false hope
of compatibility with GPL.
Note that the difference between GPL and all other licenses is that
GPL requires everything distributed with the covered work to also be
under the terms of the GPL, which leads to a problem when downstream
recipients of our code (now under GPL) make changes to it and
redistribute them to others, eventually leading to a patch submission
back to us which is GPL even though it only modifies our code. That
scenario has a definite impact on the licensing terms implied by
contributions back from those users, but we do not have that problem
with file-based copylefts.
LGPL would have been fine as well, if it weren't written in gibberish.
Beyond that, I don't agree with the theory that Apache products can't
be dependent on third-party code under some other license. I don't
see any harm in Apache producing the best interconnection software
between, for example, Java and Oracle 10i, both of which are proprietary
systems with incompatible licenses. That doesn't mean I think we
should be redistributing Java or Oracle 10i, but it does mean we need
to have flexibility in precisely defining license conditions according
to the leeway we have with the interface. The goal should be to use
the Apache License, but when that isn't possible there should be nothing
in our policies to prevent one of our projects from creating a BSD
or public domain or CDDL-covered file when doing so is necessary for
the greater good.
For the ASF, licensing is simply the way we accomplish our work legally.
It is not a goal in itself. Ideally, we would have license conditions
that allow us to be the glue within overall systems and gradually
allow non-ASF components to be replaced when and where that replacement
is necessary. The fact is that having an open source version of an
Oracle connector is useful to the public even if they don't have Oracle,
since it provides guidance on how to build a connector for the systems
that they do have.
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 15, 2006, at 12:06 AM, Roy T. Fielding wrote:
>
> I do not know of ANY such users. Users do not care at all because
> none of those licenses differ for a normal user (they only differ in
> the terms for redistribution, not use). The only people who care are
> the lawyers for large redistributors like IBM and BEA, and for them
> it is simply a matter of convenience. I don't consider them to be a
> significant portion of our users.
>
But *their* users are.
>
> I don't agree with the first two "Guiding Principles":
>
> 1. The ASF must be able to distribute works created by the Apache
> community solely under the Apache License.
>
> 2. The licensing connotation of the Apache brand must be maintained
> by ensuring all software in an Apache product, including
> third-party works, is licensed under the Apache License or
> similar terms and that steps are taken to minimize any practical
> impact on the user due to any difference in terms.
>
> They both state the same principle of license uniformity that has
> never been true for the Apache HTTP Server Project (and thus never
> for the ASF as a whole). I flatly disagree that the ASF has ever had
> anything like that as a guiding principle. The board may have passed
> a resolution last year to *add* that as a goal, but I know for a fact
> that it hasn't been implemented in the projects because it can't be
> without ripping out our build systems.
>
I must not be understanding the above. We license stuff under
the AL because that is how we want the code licensed, released
and distributed. Anything that dilutes that goal should
be actively avoided. If a ASF project is licensed under the
AL and requires an external s/w package that is NOT licensed
under the AL but the combined work has no more restrictions
that a solely AL licensed work does (eg: AL + BSD) then
we are OK with that. If, instead, the AL is subservient to
the other license, then we have destroyed what it is
we are trying to create: code usable and distributable as
widely and as freely as possible. Otherwise, the 'Why Apache
Software is Free' section is bogus.
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 15, 2006, at 1:40 AM, Cliff Schmidt wrote:
>
>> 1. The ASF must be able to distribute works created by the Apache
>> community solely under the Apache License.
>
> All I am saying here is that we should be able to redistribute our
> committers code under the Apache License, without being required to
> license it under some other restrictive license just to satisfy a
> requirement of an included strong copyleft third-party component.
>
If "we" (the ASF) are required to release/redistribute code
under any license other than the AL, then the code has no
place under the ASF. We have, for example, actively avoided
any sort of concept of dual-licensing, etc, and it appears
to me that instead of the AL being one of the guiding
principles of the ASF, it's becoming a noose that some
people want to be able to disregard willy-nilly.
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Cliff Schmidt <cl...@gmail.com>.
On 3/15/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Mar 14, 2006, at 10:40 PM, Cliff Schmidt wrote:
>
> >> 1. The ASF must be able to distribute works created by the Apache
> >> community solely under the Apache License.
> >
> > All I am saying here is that we should be able to redistribute our
> > committers code under the Apache License, without being required to
> > license it under some other restrictive license just to satisfy a
> > requirement of an included strong copyleft third-party component.
>
> Yes, you are right that I did not notice the emphasis on "created by".
> It should actually say "created within an Apache Project" since
> community has no distinct boundaries.
done -- I actually rev'd the doc to 0.52 with just that change so this
isn't unclear to anyone else.
http://people.apache.org/~cliffs/3party.html#principle1
Cliff
> I don't think that changes my opinion on the others, though.
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 14, 2006, at 10:40 PM, Cliff Schmidt wrote:
>> 1. The ASF must be able to distribute works created by the Apache
>> community solely under the Apache License.
>
> All I am saying here is that we should be able to redistribute our
> committers code under the Apache License, without being required to
> license it under some other restrictive license just to satisfy a
> requirement of an included strong copyleft third-party component.
Yes, you are right that I did not notice the emphasis on "created by".
It should actually say "created within an Apache Project" since
community has no distinct boundaries.
I don't think that changes my opinion on the others, though.
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Cliff Schmidt wrote:
>
> We obviously disagree about whether there should ever be a case where
> the corresponding source to an included third-party component is a
> separate download or whether it must be included in the product
> download. I'd like to hear some other opinions -- so far, you and I
> are the only ones who have put forth any arguments on this point.
AFIAC - there's no reason to ship - let them obtain source + binaries
seperately 'from the horses mouth' so to speak. But I'm probably in
the minority here, I'm sure some projects have a different perspective.
That said - I'm quite against this in shipped projects and have relatively
little issue with an 'easy to obtain' tarball from incubator - as we know
incubation projects will exist that are in the transformative process of
moving to ASL-spirit licensing.
> We also disagree about how much to concern ourselves with Apache users
> who redistribute our products. My experience is that even small
> companies that redistribute software prefer Apache because they don't
> have to worry how they license their derivative and/or larger works.
Let's be clear; this is not strictly redistribution.
I used to write software to generate revenue documents (e.g. money by other
colors.) The GPL is quite specific - it's the USERS who must be given the
source. Had I based this on GPL code, every printer operator would have
had access to that code, code which was propritary and contained trade
secrets. This isn't a case of using the code to sell software and services,
but applying the code to a business case internally. (Using it, as it were
in my case, to 'make money' - literally ;-)
Anyways, my point is that folks look at the narrow picture of redistribution
while there are other tangents to consider. So from my perspective, GPL
code doesn't belong here in the first place, and where it does (rarely)
occur for no other options (e.g. incubation efforts) it should be branded,
and IMHO obtained independently by the end user.
You asked for 2c - I gave you a buck :)
Bill
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/14/06, Cliff Schmidt <cl...@gmail.com> wrote:
> We obviously disagree about whether there should ever be a case where
> the corresponding source to an included third-party component is a
> separate download or whether it must be included in the product
> download. I'd like to hear some other opinions -- so far, you and I
> are the only ones who have put forth any arguments on this point.
I'm fine with bundling software with different non-ALv2 licenses as
long as we have truth in labeling. Many ASF projects haven't followed
the LICENSE style of httpd (i.e. including all licenses there) - so
getting all projects to do that would be a big start.
That said, I don't think we need to hit our users over the head with
our licensing beliefs - just because a piece is licensed under, say,
CDDL shouldn't mean that we force users to go through extra steps
somewhere else to download that component. (Distributing GPL would be
a no-no.)
And, of course, the ASF shouldn't make any changes to any software
that those changes can't itself be licensed under the ALv2. -- justin
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Cliff Schmidt <cl...@gmail.com>.
Roy,
We obviously disagree about whether there should ever be a case where
the corresponding source to an included third-party component is a
separate download or whether it must be included in the product
download. I'd like to hear some other opinions -- so far, you and I
are the only ones who have put forth any arguments on this point.
We also disagree about how much to concern ourselves with Apache users
who redistribute our products. My experience is that even small
companies that redistribute software prefer Apache because they don't
have to worry how they license their derivative and/or larger works.
If we really only cared about users who don't redistribute derivative
works, why wouldn't the GPL be a perfectly acceptable license for our
products?
So, I think these are two disagreements, but I also think there is at
least one major misunderstanding. If this explanation makes any sense
to you, let me know how I can make the offending parts of the policy
more clear:
The policy absolutely does not require "license uniformity". There
are currently 14 licenses listed in the policy that are perfectly fine
to be used for third-party works in an Apache product (although, I
realize that you believe six of them are useless if the source can't
be in the same download). So, I'm not sure why you think that I am
advocating that everything in the Apache product should be under the
Apache License. If I thought that, this policy document would have
been a whole lot shorter -- the hard part is drawing a line to define
what licenses are excluded. Believe me, I've been aware of the
interest in distributing CDDL jars from the very beginning; this
policy explicitly allows CDDL-licensed works to be redistributed.
Maybe this first guiding principle of the document that you said you
disagreed with is the source of confusion:
> 1. The ASF must be able to distribute works created by the Apache
> community solely under the Apache License.
All I am saying here is that we should be able to redistribute our
committers code under the Apache License, without being required to
license it under some other restrictive license just to satisfy a
requirement of an included strong copyleft third-party component.
Do you really disagree with this, or do I need to reword that
guideline to better indicate my intention?
Cliff
On 3/14/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Mar 14, 2006, at 4:11 PM, Cliff Schmidt wrote:
> > On 3/14/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> >> In my opinion, no
> >> source means no distribution from the ASF, regardless of anyone's
> >> opinion on how inconvenient that might be for users. Emphasizing
> >> that some perfectly reasonable open source code must only be
> >> redistributed in binary form is contrary to our founding principle.
> >
> > I agree that we should only be distributing open source software -->
> > see http://people.apache.org/~cliffs/3party.html#criterion1.
> >
> > However, in the case of including open source software with
> > copyleft/reciprocal terms, I believe it is preferable to leave the
> > source version out of the product download, even though it is an easy
> > download from a link listed in the product's NOTICE file.
>
> And I don't. That's okay -- we don't have to agree on everything.
> In my opinion, if we only supply a link to the source then we only
> supply a link to the binary, and there is no reason to include
> anything in the NOTICE file.
>
> Open source does not include binary-only libraries, even by reference.
> The binary packages that Apache distributes are not open source. The
> only reason we distribute them is for the convenience of Java and Win32
> folks for whom compiling the code they receive is a burden.
> Nevertheless,
> the rule should be that anything we distribute as a binary is also
> redistributed by us as open source.
>
> > I've explained my rationale here:
> > http://people.apache.org/~cliffs/3party.html#criterion-reciprocity;
> > but, basically I think it comes down to weighing up the cost for
> > interested users to copy a link into their browsers vs. the cost for
> > users who suddenly find they are forced to license their derivative
> > distributions of an Apache product a certain way, because they didn't
> > carefully read one of the included licenses and, instead, relied on
> > the reputation of Apache products for being under the Apache License,
> > which has no such reciprocity requirements.
>
> You are missing the point. If we only redistribute the binaries, then
> we are not fulfilling the desires of recipients to receive open source
> from the ASF. The reciprocity concern is insignificant compared to the
> need for the source code. It is better to force the user to download
> the binary library from the third party site, since then they are
> presented with the opportunity to download the exact source code that
> was used to create that binary. The partial restriction that you
> describe is far worse than a total ban because it creates a dependency
> on us for software that IS NOT open source. Binaries are not open
> source.
>
> > I'm interested in hearing any other solutions to this problem, but I
> > do feel that most users of Apache software would be quite surprised to
> > find reciprocity requirements in the software they get from us. I'm
> > just trying to find a way to ease these users into this situation,
> > without any of them getting an unhappy surprise.
>
> I do not know of ANY such users. Users do not care at all because
> none of those licenses differ for a normal user (they only differ in
> the terms for redistribution, not use). The only people who care are
> the lawyers for large redistributors like IBM and BEA, and for them
> it is simply a matter of convenience. I don't consider them to be a
> significant portion of our users.
>
> > Could you tell me which part of the license criteria
> > (http://people.apache.org/~cliffs/3party.html#criteria) you disagree
> > with? Do you actually have a problem with the primary three criteria,
> > or just the part discussed above about how to package
> > copyleft/reciprocally-licensed work?
>
> I don't agree with the first two "Guiding Principles":
>
> 1. The ASF must be able to distribute works created by the Apache
> community solely under the Apache License.
>
> 2. The licensing connotation of the Apache brand must be maintained
> by ensuring all software in an Apache product, including
> third-party works, is licensed under the Apache License or
> similar terms and that steps are taken to minimize any practical
> impact on the user due to any difference in terms.
>
> They both state the same principle of license uniformity that has
> never been true for the Apache HTTP Server Project (and thus never
> for the ASF as a whole). I flatly disagree that the ASF has ever had
> anything like that as a guiding principle. The board may have passed
> a resolution last year to *add* that as a goal, but I know for a fact
> that it hasn't been implemented in the projects because it can't be
> without ripping out our build systems.
>
> I also don't agree with the additional requirements to the criteria:
>
> In addition to these requirements, if the license requires any
> degree of reciprocity, the following special requirements must
> be met:
>
> * the associated third-party software may only be distributed
> by the ASF in binary form, and
> * the ASF distribution must be prominently labeled to indicate
> the inclusion of software under reciprocal terms.
>
> The purpose behind these additional requirements are to minimize
> the chance that a user of an Apache product will create a derivative
> work of a reciprocally-licensed portion of an Apache product without
> being aware of the applicable requirements. By including only the
> object/binary form, there is less exposed surface area of the
> third-party work from which a work might be derived; this addresses
> the second guiding principle of this policy. By attaching a
> prominent
> label to the distribution and requiring an explicit action by the
> user
> to get the reciprocally-licensed source, users are less likely to be
> unaware of restrictions significantly different from those of the
> Apache License; this addresses the fourth guiding principle of this
> policy.
>
> Labeling is good. Cutting a swath through our code bases just to
> "minimize the chance" for an ignorant redistributor to stub their
> own toe is not good. It is totally irrelevant to us if a user,
> having received a set of open source software with properly described
> license terms, proceeds to modify that software and then redistribute
> it without having read and understood the terms for the part they are
> redistributing. Likewise, reciprocal terms are completely irrelevant
> for scripts, DTDs, and other source files for which distribution of
> source is a given and thus the reciprocal license terms cannot be
> violated even by an ignorant redistributor that unknowingly modifies
> and redistributes a modified version of those files.
>
> The ASF is not like the FSF and should not behave like it. We don't
> need license uniformity. For example, we are currently engaged at
> various levels with Sun in trying to get them to make more of their
> code released as CDDL so that we can use it for JCP implementations.
> That's not going to fly very well if we turn around and tell the
> entire world that the ASF will only use Apache License code. It will
> force anyone who is trying to build bridging code to go elsewhere.
>
> ....Roy
>
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 14, 2006, at 4:11 PM, Cliff Schmidt wrote:
> On 3/14/06, Roy T. Fielding <fi...@gbiv.com> wrote:
>> In my opinion, no
>> source means no distribution from the ASF, regardless of anyone's
>> opinion on how inconvenient that might be for users. Emphasizing
>> that some perfectly reasonable open source code must only be
>> redistributed in binary form is contrary to our founding principle.
>
> I agree that we should only be distributing open source software -->
> see http://people.apache.org/~cliffs/3party.html#criterion1.
>
> However, in the case of including open source software with
> copyleft/reciprocal terms, I believe it is preferable to leave the
> source version out of the product download, even though it is an easy
> download from a link listed in the product's NOTICE file.
And I don't. That's okay -- we don't have to agree on everything.
In my opinion, if we only supply a link to the source then we only
supply a link to the binary, and there is no reason to include
anything in the NOTICE file.
Open source does not include binary-only libraries, even by reference.
The binary packages that Apache distributes are not open source. The
only reason we distribute them is for the convenience of Java and Win32
folks for whom compiling the code they receive is a burden.
Nevertheless,
the rule should be that anything we distribute as a binary is also
redistributed by us as open source.
> I've explained my rationale here:
> http://people.apache.org/~cliffs/3party.html#criterion-reciprocity;
> but, basically I think it comes down to weighing up the cost for
> interested users to copy a link into their browsers vs. the cost for
> users who suddenly find they are forced to license their derivative
> distributions of an Apache product a certain way, because they didn't
> carefully read one of the included licenses and, instead, relied on
> the reputation of Apache products for being under the Apache License,
> which has no such reciprocity requirements.
You are missing the point. If we only redistribute the binaries, then
we are not fulfilling the desires of recipients to receive open source
from the ASF. The reciprocity concern is insignificant compared to the
need for the source code. It is better to force the user to download
the binary library from the third party site, since then they are
presented with the opportunity to download the exact source code that
was used to create that binary. The partial restriction that you
describe is far worse than a total ban because it creates a dependency
on us for software that IS NOT open source. Binaries are not open
source.
> I'm interested in hearing any other solutions to this problem, but I
> do feel that most users of Apache software would be quite surprised to
> find reciprocity requirements in the software they get from us. I'm
> just trying to find a way to ease these users into this situation,
> without any of them getting an unhappy surprise.
I do not know of ANY such users. Users do not care at all because
none of those licenses differ for a normal user (they only differ in
the terms for redistribution, not use). The only people who care are
the lawyers for large redistributors like IBM and BEA, and for them
it is simply a matter of convenience. I don't consider them to be a
significant portion of our users.
> Could you tell me which part of the license criteria
> (http://people.apache.org/~cliffs/3party.html#criteria) you disagree
> with? Do you actually have a problem with the primary three criteria,
> or just the part discussed above about how to package
> copyleft/reciprocally-licensed work?
I don't agree with the first two "Guiding Principles":
1. The ASF must be able to distribute works created by the Apache
community solely under the Apache License.
2. The licensing connotation of the Apache brand must be maintained
by ensuring all software in an Apache product, including
third-party works, is licensed under the Apache License or
similar terms and that steps are taken to minimize any practical
impact on the user due to any difference in terms.
They both state the same principle of license uniformity that has
never been true for the Apache HTTP Server Project (and thus never
for the ASF as a whole). I flatly disagree that the ASF has ever had
anything like that as a guiding principle. The board may have passed
a resolution last year to *add* that as a goal, but I know for a fact
that it hasn't been implemented in the projects because it can't be
without ripping out our build systems.
I also don't agree with the additional requirements to the criteria:
In addition to these requirements, if the license requires any
degree of reciprocity, the following special requirements must
be met:
* the associated third-party software may only be distributed
by the ASF in binary form, and
* the ASF distribution must be prominently labeled to indicate
the inclusion of software under reciprocal terms.
The purpose behind these additional requirements are to minimize
the chance that a user of an Apache product will create a derivative
work of a reciprocally-licensed portion of an Apache product without
being aware of the applicable requirements. By including only the
object/binary form, there is less exposed surface area of the
third-party work from which a work might be derived; this addresses
the second guiding principle of this policy. By attaching a
prominent
label to the distribution and requiring an explicit action by the
user
to get the reciprocally-licensed source, users are less likely to be
unaware of restrictions significantly different from those of the
Apache License; this addresses the fourth guiding principle of this
policy.
Labeling is good. Cutting a swath through our code bases just to
"minimize the chance" for an ignorant redistributor to stub their
own toe is not good. It is totally irrelevant to us if a user,
having received a set of open source software with properly described
license terms, proceeds to modify that software and then redistribute
it without having read and understood the terms for the part they are
redistributing. Likewise, reciprocal terms are completely irrelevant
for scripts, DTDs, and other source files for which distribution of
source is a given and thus the reciprocal license terms cannot be
violated even by an ignorant redistributor that unknowingly modifies
and redistributes a modified version of those files.
The ASF is not like the FSF and should not behave like it. We don't
need license uniformity. For example, we are currently engaged at
various levels with Sun in trying to get them to make more of their
code released as CDDL so that we can use it for JCP implementations.
That's not going to fly very well if we turn around and tell the
entire world that the ASF will only use Apache License code. It will
force anyone who is trying to build bridging code to go elsewhere.
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Cliff Schmidt <cl...@gmail.com>.
On 3/14/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> In my opinion, no
> source means no distribution from the ASF, regardless of anyone's
> opinion on how inconvenient that might be for users. Emphasizing
> that some perfectly reasonable open source code must only be
> redistributed in binary form is contrary to our founding principle.
I agree that we should only be distributing open source software -->
see http://people.apache.org/~cliffs/3party.html#criterion1.
However, in the case of including open source software with
copyleft/reciprocal terms, I believe it is preferable to leave the
source version out of the product download, even though it is an easy
download from a link listed in the product's NOTICE file.
I've explained my rationale here:
http://people.apache.org/~cliffs/3party.html#criterion-reciprocity;
but, basically I think it comes down to weighing up the cost for
interested users to copy a link into their browsers vs. the cost for
users who suddenly find they are forced to license their derivative
distributions of an Apache product a certain way, because they didn't
carefully read one of the included licenses and, instead, relied on
the reputation of Apache products for being under the Apache License,
which has no such reciprocity requirements.
I'm interested in hearing any other solutions to this problem, but I
do feel that most users of Apache software would be quite surprised to
find reciprocity requirements in the software they get from us. I'm
just trying to find a way to ease these users into this situation,
without any of them getting an unhappy surprise.
...
> At the same time, the above is the limit of our obligations. There
> is no need to limit our software to one Apache License. There is a
> desire, sure, but no obligation. I would prefer to have a list of
> allowable licenses and a standard for full disclosure of those licenses
> within each distribution.
I agree, and I think this policy does most of that. What it doesn't
do (outline how to disclose those licenses in each distribution) is
coming in the document I am currently drafting (referred to in this
policy as "Receiving and Distributing Contributions") on the copyright
notice requirements, license disclosures, crypto export issues, and
more.
...
> So, while I think the policy is carefully worded and well thought-out,
> there is no point in having me review it in detail because the
> criteria chosen is, in my opinion, wrong for the ASF. We should be
> focusing on how to legally distribute open source of any license,
> not limiting the scope of licenses that are allowed to be distributed
> (aside from the GPL, which is self-limiting).
Could you tell me which part of the license criteria
(http://people.apache.org/~cliffs/3party.html#criteria) you disagree
with? Do you actually have a problem with the primary three criteria,
or just the part discussed above about how to package
copyleft/reciprocally-licensed work?
Cliff
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 13, 2006, at 5:49 PM, Cliff Schmidt wrote:
> See http://people.apache.org/~cliffs/3party.html for a draft policy
> regarding the use of third-party works in Apache products and their
> various licenses. The policy includes license criteria, lists of
> specifically authorized and excluded licenses, a license labeling
> policy, options for works under excluded licenses, and a transition
> policy.
Sorry I haven't been able to keep up with this discussion. I am
slowly working through my backlog of interesting stuff that got
dropped last month due to court deadlines and W3C TAG stuff, both
of which are now out of the way.
All of my concerns are about policy, not legality, and I think it is a
shame that we have to repeat all of the discussions that we had on the
licensing mailing list (see private archives). But I don't have any
specific things to point to because the meat of our licensing
discussions
and philosophy took place during phone meetings and conferences.
The #1 principle of the ASF is embodied in our certificate of
incorporation
as stated by me to the State of Delaware, namely
<http://www.apache.org/foundation/records/certificate.html>
The purpose of the Corporation is to engage in any lawful act or
activity for which corporations which are organized not for profit
may be organized under the General Corporation Law of the State of
Delaware, including the creation and maintenance of "open source"
software distributed by the Corporation to the public at no charge.
I know that is written in an open-ended way, for legal reasons, but
it really has been the intention of the Foundation from its very
beginning to be a distributor of open source. In my opinion, no
source means no distribution from the ASF, regardless of anyone's
opinion on how inconvenient that might be for users. Emphasizing
that some perfectly reasonable open source code must only be
redistributed in binary form is contrary to our founding principle.
At the same time, the above is the limit of our obligations. There
is no need to limit our software to one Apache License. There is a
desire, sure, but no obligation. I would prefer to have a list of
allowable licenses and a standard for full disclosure of those licenses
within each distribution. That is how the HTTP server has always
operated, and we don't have the legal capacity to go back and rewrite
history just to make license uniformity a goal.
My work on the Apache License was intended to make it entirely
compatible with other open source licenses when distributed together.
I see that work being steadily eroded by what is essentially a PR
simplification. I honestly don't care how many lawyers are required
by our redistributors to understand the detailed licensing conditions
for each product -- they are going to do that anyway for due diligence.
If they don't like it, then they don't need to redistribute our
software under their own license. It is not *OUR* problem.
Our problem is providing open source software to the public.
So, while I think the policy is carefully worded and well thought-out,
there is no point in having me review it in detail because the
criteria chosen is, in my opinion, wrong for the ASF. We should be
focusing on how to legally distribute open source of any license,
not limiting the scope of licenses that are allowed to be distributed
(aside from the GPL, which is self-limiting).
....Roy
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Dan Diephouse <da...@envoisolutions.com>.
Spectacular work Cliff. This is great to see. Looks like you've put a
lot of thought into clarifying Apache's license stance!
- Dan
Cliff Schmidt wrote:
> See http://people.apache.org/~cliffs/3party.html for a draft policy
> regarding the use of third-party works in Apache products and their
> various licenses. The policy includes license criteria, lists of
> specifically authorized and excluded licenses, a license labeling
> policy, options for works under excluded licenses, and a transition
> policy.
>
> Please send any comments, concerns, feedback, and flames to this list,
> unless you have a special need to keep your comments private (since
> this list has a publicly accessible archive).
>
> Although this is an internal policy directed at Apache committers and
> PMC members, it impacts how Apache products will be licensed, which
> Apache users obviously have an interest in. Therefore, I'm also
> interested in any feedback from a user's point of view.
>
> Thanks,
>
> Cliff Schmidt
> Legal Affairs Officer
> Apache Software Foundation
>
>
> ---------------------------------------------------------------------
> 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
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Jesse Kuhnert <jk...@gmail.com>.
I like it....Though I can see now why in some cases it is easier to be more
restrictive in wording than less, as some might interpret things
incorrectly.
If I may be so bold, a wiki-able FAQ entry that starts to get built from
this might help out a lot. I know there is one floating around for jakarta
right now, but some sort of officially condoned board FAQ might be a lot
more helpful. I'd be happy to start it off with something along the lines of
the example I gave.
j
On 3/14/06, Cliff Schmidt <cl...@apache.org> wrote:
>
>
> On Mar 14, 2006, at 8:06 AM, Jesse Kuhnert wrote:
>
> >
> > > provided that the "ant" build must explicitly be called for this
> > > particular target, and that it also makes very clear to the user
> > > that the code they are about to download(ibiblio)/build is not
> > > apache code and is subject to alternate licensing?
> >
> > Any build script distributed by a PMC that would cause an LGPL jar to
> > be downloaded is allowed "provided that the script or documentation
> > is not included in the product and that any resulting retrieval of a
> > prohibited work is accompanied by a clear identification of the
> > associated license." (not just a note that the license may be
> > different) -- see http://people.apache.org/~cliffs/
> > 3party.html#options-build.
> >
> >
> > So, the build script ~is~ allowed to do this external download, but
> > technically speaking the build script can't actually exist in the
> > apache project? More or less this means anything like this needs to
> > be hosted elsewhere?
> >
> > Sorry for being so dim about this, just trying to be sure I'm
> > reading things correctly.
>
> I see why you are confused. The current paragraph does say it can be
> distributed from an apache.org server, but just not part of the
> product download. The idea was to try to as cleanly as possible
> separate what is the product and what is a system requirement of the
> product. As long as the ASF is not distributing the system
> requirements, they can include things under the LGPL, GPL, or a
> Microsoft End User License Agreement. So, I think it's important to
> make the distinction between the product and what it needs to run.
>
> So, to the issue of helping someone download some system requirement
> that is available somewhere, I don't think we should be making that
> difficult -- just clearly not part of the product. Whether the
> product download actually includes the script that will get it
> probably doesn't matter. So what about a revision of that paragraph
> from:
>
> " * YOU MAY ALSO distribute build scripts or documentation from
> apache.org servers intended to assist users with validating or even
> acquiring and configuring system requirements for an Apache product,
> provided that the script or documentation is not included in the
> product and that any resulting retrieval of a prohibited work is
> accompanied by a clear identification of the associated license."
>
> to:
>
> " * YOU MAY ALSO include within an Apache product a documented,
> non-default, build option to allow users to explicitly choose to
> validate, retrieve, or configure any system requirement for an Apache
> product, provided that such option is not likely to be confused with
> the standard product build and that any resulting retrieval of a
> prohibited work is accompanied by a clear identification of its
> associated license."
>
>
> Thoughts, anyone?
>
> Cliff
>
>
>
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Cliff Schmidt <cl...@apache.org>.
On Mar 14, 2006, at 8:06 AM, Jesse Kuhnert wrote:
>
> > provided that the "ant" build must explicitly be called for this
> > particular target, and that it also makes very clear to the user
> > that the code they are about to download(ibiblio)/build is not
> > apache code and is subject to alternate licensing?
>
> Any build script distributed by a PMC that would cause an LGPL jar to
> be downloaded is allowed "provided that the script or documentation
> is not included in the product and that any resulting retrieval of a
> prohibited work is accompanied by a clear identification of the
> associated license." (not just a note that the license may be
> different) -- see http://people.apache.org/~cliffs/
> 3party.html#options-build.
>
>
> So, the build script ~is~ allowed to do this external download, but
> technically speaking the build script can't actually exist in the
> apache project? More or less this means anything like this needs to
> be hosted elsewhere?
>
> Sorry for being so dim about this, just trying to be sure I'm
> reading things correctly.
I see why you are confused. The current paragraph does say it can be
distributed from an apache.org server, but just not part of the
product download. The idea was to try to as cleanly as possible
separate what is the product and what is a system requirement of the
product. As long as the ASF is not distributing the system
requirements, they can include things under the LGPL, GPL, or a
Microsoft End User License Agreement. So, I think it's important to
make the distinction between the product and what it needs to run.
So, to the issue of helping someone download some system requirement
that is available somewhere, I don't think we should be making that
difficult -- just clearly not part of the product. Whether the
product download actually includes the script that will get it
probably doesn't matter. So what about a revision of that paragraph
from:
" * YOU MAY ALSO distribute build scripts or documentation from
apache.org servers intended to assist users with validating or even
acquiring and configuring system requirements for an Apache product,
provided that the script or documentation is not included in the
product and that any resulting retrieval of a prohibited work is
accompanied by a clear identification of the associated license."
to:
" * YOU MAY ALSO include within an Apache product a documented,
non-default, build option to allow users to explicitly choose to
validate, retrieve, or configure any system requirement for an Apache
product, provided that such option is not likely to be confused with
the standard product build and that any resulting retrieval of a
prohibited work is accompanied by a clear identification of its
associated license."
Thoughts, anyone?
Cliff
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Jesse Kuhnert <jk...@gmail.com>.
> > provided that the "ant" build must explicitly be called for this
> > particular target, and that it also makes very clear to the user
> > that the code they are about to download(ibiblio)/build is not
> > apache code and is subject to alternate licensing?
>
> Any build script distributed by a PMC that would cause an LGPL jar to
> be downloaded is allowed "provided that the script or documentation
> is not included in the product and that any resulting retrieval of a
> prohibited work is accompanied by a clear identification of the
> associated license." (not just a note that the license may be
> different) -- see http://people.apache.org/~cliffs/
> 3party.html#options-build.
>
>
So, the build script ~is~ allowed to do this external download, but
technically speaking the build script can't actually exist in the apache
project? More or less this means anything like this needs to be hosted
elsewhere?
Sorry for being so dim about this, just trying to be sure I'm reading things
correctly.
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Cliff Schmidt <cl...@apache.org>.
On Mar 14, 2006, at 7:26 AM, Jesse Kuhnert wrote:
> "creek .....creeek....creeek" those are crickets ;)
Maybe those were crickets, because it was evening time for me when
you sent your post, and it's now barely morning.
> On 3/13/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> Sounds like a very reasonable outline, would I be correct in
> thinking that I can now:
>
> -) Include an LGPL jar as part of a non-standard build of a demo
> application,
As long as you don't really mean including the LGPL jar in anything
distributed from apache.org...
> provided that the "ant" build must explicitly be called for this
> particular target, and that it also makes very clear to the user
> that the code they are about to download(ibiblio)/build is not
> apache code and is subject to alternate licensing?
Any build script distributed by a PMC that would cause an LGPL jar to
be downloaded is allowed "provided that the script or documentation
is not included in the product and that any resulting retrieval of a
prohibited work is accompanied by a clear identification of the
associated license." (not just a note that the license may be
different) -- see http://people.apache.org/~cliffs/
3party.html#options-build.
>
> Ie I would like to build a demo app for tapestry that uses
> hibernate as the underlying DB access layer - with all necessary
> user acknowledged license restrictions in place- is this possible?
You could also have the PMC distribute a demo app that considers
Hibernate a system requirement, since "YOU MAY include code within
the Apache product necessary to achieve compatibility with a
prohibited work through the use of API calls, "bridge code", or
protocols, provided that the compatibility code was contributed under
a CLA." -- see http://people.apache.org/~cliffs/3party.html#options-
inproduct.
Cliff
>
>
> On 3/13/06, Cliff Schmidt <cl...@apache.org> wrote: See http://
> people.apache.org/~cliffs/3party.html for a draft policy
> regarding the use of third-party works in Apache products and their
> various licenses. The policy includes license criteria, lists of
> specifically authorized and excluded licenses, a license labeling
> policy, options for works under excluded licenses, and a transition
> policy.
>
> Please send any comments, concerns, feedback, and flames to this
> list, unless you have a special need to keep your comments private
> (since this list has a publicly accessible archive).
>
> Although this is an internal policy directed at Apache committers and
> PMC members, it impacts how Apache products will be licensed, which
> Apache users obviously have an interest in. Therefore, I'm also
> interested in any feedback from a user's point of view.
>
> Thanks,
>
> Cliff Schmidt
> Legal Affairs Officer
> Apache Software Foundation
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Jesse Kuhnert <jk...@gmail.com>.
"creek .....creeek....creeek" those are crickets ;)
On 3/13/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> Sounds like a very reasonable outline, would I be correct in thinking that
> I can now:
>
> -) Include an LGPL jar as part of a non-standard build of a demo
> application, provided that the "ant" build must explicitly be called for
> this particular target, and that it also makes very clear to the user that
> the code they are about to download(ibiblio)/build is not apache code and is
> subject to alternate licensing?
>
> Ie I would like to build a demo app for tapestry that uses hibernate as
> the underlying DB access layer - with all necessary user acknowledged
> license restrictions in place- is this possible?
>
> jesse
>
>
> On 3/13/06, Cliff Schmidt <cl...@apache.org> wrote:
> >
> > See http://people.apache.org/~cliffs/3party.html<http://people.apache.org/%7Ecliffs/3party.html>for a draft policy
> > regarding the use of third-party works in Apache products and their
> > various licenses. The policy includes license criteria, lists of
> > specifically authorized and excluded licenses, a license labeling
> > policy, options for works under excluded licenses, and a transition
> > policy.
> >
> > Please send any comments, concerns, feedback, and flames to this
> > list, unless you have a special need to keep your comments private
> > (since this list has a publicly accessible archive).
> >
> > Although this is an internal policy directed at Apache committers and
> > PMC members, it impacts how Apache products will be licensed, which
> > Apache users obviously have an interest in. Therefore, I'm also
> > interested in any feedback from a user's point of view.
> >
> > Thanks,
> >
> > Cliff Schmidt
> > Legal Affairs Officer
> > Apache Software Foundation
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Jesse Kuhnert <jk...@gmail.com>.
Sounds like a very reasonable outline, would I be correct in thinking that I
can now:
-) Include an LGPL jar as part of a non-standard build of a demo
application, provided that the "ant" build must explicitly be called for
this particular target, and that it also makes very clear to the user that
the code they are about to download(ibiblio)/build is not apache code and is
subject to alternate licensing?
Ie I would like to build a demo app for tapestry that uses hibernate as the
underlying DB access layer - with all necessary user acknowledged license
restrictions in place- is this possible?
jesse
On 3/13/06, Cliff Schmidt <cl...@apache.org> wrote:
>
> See http://people.apache.org/~cliffs/3party.html for a draft policy
> regarding the use of third-party works in Apache products and their
> various licenses. The policy includes license criteria, lists of
> specifically authorized and excluded licenses, a license labeling
> policy, options for works under excluded licenses, and a transition
> policy.
>
> Please send any comments, concerns, feedback, and flames to this
> list, unless you have a special need to keep your comments private
> (since this list has a publicly accessible archive).
>
> Although this is an internal policy directed at Apache committers and
> PMC members, it impacts how Apache products will be licensed, which
> Apache users obviously have an interest in. Therefore, I'm also
> interested in any feedback from a user's point of view.
>
> Thanks,
>
> Cliff Schmidt
> Legal Affairs Officer
> Apache Software Foundation
>
>
> ---------------------------------------------------------------------
> 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
>
>
Re: Two weeks left for comments! (was: [Request For Comment] Third-Party Licensing Policy)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 18 March 2006 07:09, Cliff Schmidt wrote:
> I know there are more of you out there with comments or concerns
> about this policy.
I think Roy summarized my personal tack on this;
On Wednesday 15 March 2006 02:49, Roy T. Fielding wrote:
> In my opinion, no source means no distribution from the ASF, regardless
> of anyone's opinion on how inconvenient that might be for users.
> Emphasizing that some perfectly reasonable open source code must only
> be redistributed in binary form is contrary to our founding principle.
> At the same time, the above is the limit of our obligations. There
> is no need to limit our software to one Apache License.
Now, having said that;
It helps many users to "know" that ASF software is normally unencumbered, and
we should *strive* for that position. I like it, many others like it.
But, speaking for myself, it would be enough that each TLP was required to
have a "License List" on the main page, where the licenses of dependencies
were clearly stated. A quick glimpse and I can make my own judgement.
So, perhaps the "Policy" should be more flexible in favour of the PMCs (as Roy
is suggesting) and made more into "Guidelines" to support the PMCs in their
decision making and lower the number of questions to this list.
Cheers
Niclas
---------------------------------------------------------------------
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
Two weeks left for comments! (was: [Request For Comment] Third-Party Licensing Policy)
Posted by Cliff Schmidt <cl...@apache.org>.
I know there are more of you out there with comments or concerns
about this policy. Please take the time to read the policy and send
in your thoughts within the next two weeks, by Friday, March 31st.
The policy will become final in some time in April, depending on how
long it takes to resolve whatever comments were received in March.
Thanks,
Cliff
On Mar 13, 2006, at 5:49 PM, Cliff Schmidt wrote:
> See http://people.apache.org/~cliffs/3party.html for a draft policy
> regarding the use of third-party works in Apache products and their
> various licenses. The policy includes license criteria, lists of
> specifically authorized and excluded licenses, a license labeling
> policy, options for works under excluded licenses, and a transition
> policy.
>
> Please send any comments, concerns, feedback, and flames to this
> list, unless you have a special need to keep your comments private
> (since this list has a publicly accessible archive).
>
> Although this is an internal policy directed at Apache committers
> and PMC members, it impacts how Apache products will be licensed,
> which Apache users obviously have an interest in. Therefore, I'm
> also interested in any feedback from a user's point of view.
>
> Thanks,
>
> Cliff Schmidt
> Legal Affairs Officer
> Apache Software Foundation
>
---------------------------------------------------------------------
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
Re: [Request For Comment] Third-Party Licensing Policy
Posted by Niall Pemberton <ni...@gmail.com>.
This is a great piece of work and provides alot of clarity in a
confusing area. I was just looking at something that is CDDL licensed
and went to your doc to check to see what it said about that license -
once this is accepted having something authoritative to refer to will
be a big step forward. Thanks for your efforts - v.impressive.
Niall
On 3/14/06, Cliff Schmidt <cl...@apache.org> wrote:
> See http://people.apache.org/~cliffs/3party.html for a draft policy
> regarding the use of third-party works in Apache products and their
> various licenses. The policy includes license criteria, lists of
> specifically authorized and excluded licenses, a license labeling
> policy, options for works under excluded licenses, and a transition
> policy.
>
> Please send any comments, concerns, feedback, and flames to this
> list, unless you have a special need to keep your comments private
> (since this list has a publicly accessible archive).
>
> Although this is an internal policy directed at Apache committers and
> PMC members, it impacts how Apache products will be licensed, which
> Apache users obviously have an interest in. Therefore, I'm also
> interested in any feedback from a user's point of view.
>
> Thanks,
>
> Cliff Schmidt
> Legal Affairs Officer
> Apache Software Foundation
---------------------------------------------------------------------
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