www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject RE: Third Party FOSS licenses
Date Tue, 04 Aug 2015 06:46:29 GMT
My brief response, and having hopefully answered your top post question for
actual cases, I have nothing further to contribute to this thread...

On Aug 3, 2015 16:48, "Lawrence Rosen" <lrosen@rosenlaw.com> wrote:
> William A Rowe Jr. wrote:
> > I have a number of downstream customers who do fix source code.
> You are one of many Apache contributors who help downstream customers
"fix" their software. We're pleased that many of your customers give those
changes back even when our ALv2 FOSS license doesn't demand reciprocation.

As a matter of fact, many changes arrive already completed.  My customers
are a mixture of competent users, but also many skilled developers
maintaining open and closed sources within their own corporate ecosystems.

> Others refuse.

Actually those who cannot contribute back upstream are quite remorseful
about it, and have put careers on the line walking up and down the
management chain and their legal department to investigate any solution
that would work.

Your framing reminds me of how much you detest that group of users.  That's
your prerogative but you don't speak for the ASF as a whole, or even a
significant large minority.

> > Any encumbrance such as DRM clauses or copyleft will never be
acceptable to that subset of our users.


> I admit that "copyleft" includes MPLv2, EPL, GPL, and lots of other
licenses, although DRM for binaries is irrelevant for FOSS software. And
true enough, as long as those components are and remain FOSS, you are free
to create derivative works but you must reciprocate with your license.

Which is why they are category X, yes.  Where they are optionally part of a
larger combination of ASF and external works, whether X or B, that provides
the benefit of a larger FOSS ecosystem, but its long been codified in
policy that ASF works cannot require such components to be functional.

> With my sincere apology I remind you that license conditions are the
right of the author. Apache members including you and me usually prefer
ALv2 but we don't dictate the licenses for valuable FOSS components
elsewhere. Again, that includes important software from the Eclipse and
Linux Foundations and from MPLv2 projects. I am not speaking of random
collections of third party code dumped into an Apache project. And I'm not
recommending GPL code unless it is accompanied by an "exception" for Larger
Works. No Apache PMC is that amateurish as to accept dangerous crap.

So you suggest, but this appears to be at odds with your many other
statements on this subject r.e. ASF A/B/X classification.

> Obviously you and I personally prefer incorporating "fixes" back into
Apache projects. The fact that some of our software will be under a
reciprocal FOSS license only helps that goal, so I'm not philosophically
sorry for it.

I seriously doubt our ASF software ever will.  I indeed have contributed
works under BSD, LGPL and GPL terms, to foundations or projects where those
are appropriate.  At the ASF we would reject the later two.  In your words,
'helps that goal' is code for the agenda of the GPL, which has its place
elsewhere, but not here.

> But for those who refuse to contribute back, there is a simple response
that will only increase the revenue for consultants and programmers like
you: "A skilled consultant can remove and replace the unacceptable FOSS
components for a fee, or perhaps get you a commercial license from the

Indeed.  The APR project has a set of interfaces for a number of key value
data stores.  The license terms vary widely.  In creating binaries, the
user may combine with whichever are both acceptably licensed and offer
acceptable performance.  A downstream licensor such as some BSDs might
never include the [L]GPL providers, but has other effective options to
combine with BSD licensed clients.

If projects seek to build something that only functions with [L]GPL
solutions, it is a issue and that project has better homes elsewhere in the
sphere of FOSS foundations.

Indeed, dependencies can be resolved, but here the onus is on the PMC to
find those alternatives.  One incubating project already demonstrated they
could not remove a key ffmpeg dependent, and that project, warned early on,
was eventually retired without graduating.

> And anyway, such decisions are not yours and mine to make, but for each
PMC and each customer to decide for itself. That's the policy change.

No, the PMC doesn't have that authority until the policy is changed. Jim
may be vested by the board to guide policy, but I am certain he would not
do so without the advise and consent of the board itself, under the
direction of the members.  You know how to put forward a resolution for
consideration to either the board and/or the members.  That might be a good
place to start (again).

View raw message