www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lawrence Rosen" <lro...@rosenlaw.com>
Subject RE: Third Party FOSS licenses
Date Mon, 03 Aug 2015 21:46:57 GMT
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. 

 

Others refuse. 

 

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

 

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.

 

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.

 

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 author."  

 

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.

 

/Larry

 

Lawrence Rosen

"If this were legal advice it would have been accompanied by a bill."

 

From: William A Rowe Jr [mailto:wrowe@rowe-clan.net] 
Sent: Monday, August 3, 2015 12:36 PM
To: legal-discuss@apache.org; Lawrence Rosen <lrosen@rosenlaw.com>
Subject: Re: Third Party FOSS licenses

 

On Mon, Aug 3, 2015 at 12:30 PM, Lawrence Rosen <lrosen@rosenlaw.com <mailto:lrosen@rosenlaw.com>
> wrote:

 

The reasons that there are so many FOSS licenses is mostly because of other things (patents,
defensive termination, "corresponding source," the scale of attribution conditions, warranties,
static linking, DRM prohibitions) than what Sam is asking about. At least, I think so. Sometimes
Sam's questions here go wildly into complex, multi-layered hypotheticals that can be boiled
down to asking about whether companies like IBM, Microsoft, Google, Adobe, etc., are free
to copy and create derivative works of all Apache products even under proprietary licenses.
 The answer is always YES as long as the components – including the ALv2 components –
are and remain FOSS. Nobody is allowed to change that. Read our license and our attribution
notices and our source code archives.

 

"as long as"... there you go again.  The origin of the source is and always remains FOSS,
the derivative (be it a fork, an extention, GNU static linkage of a larger work, etc etc ad
nauseam) need not.

 

Let me give you a concrete and coherent example.  You will disagree, but that's your privilege
as a person.

 

I have a number of downstream customers who do fix source code.  They enhance it.  They do
not share that source code with their downstream users (usually employees or customers of
their own who are handed a black box from the development team).  Many of them want to give
their changes back upstream.

 

I'm often able to help get such changes back to the ASF, but far from always.  Issues such
as liability, reputation, compartmentalization, even corporate compliance prevent these employees
from exercising their interest in pushing good changes back upstream, and there are many cases
I cannot help.  In fact I'm sometimes barred by a corporate policy of knowing what source
code changes they may or may not have in place, even as I'm contracted to help them solve
their problem with little visibility into the specific problem.  I'm even encumbered by my
relationships from disclosing anything much more specific than that in the most complex cases.

 

If a customer extended their security modules and dropped those on user workstations, those
users, under the terms of the GPL for example, are suggested that they have a right to see
that source code under those licensing terms. Corporate policy says that source code and internal
corporate knowledge stays behind the curtain, even though they would like to start from trusted
and well validated OSS software.  So that GPL to many customers is simply unacceptable (and
let's not launch into the issues of EGPL).  Any encumbrance such as DRM clauses or copyleft
will never be acceptable to that subset of our users.

 

I read your comments, Larry, that all OSS uses of ASF software are fine by you, and all other
such downstream applications of ASF software are unwanted by you.  I'm sorry we aren't bridging
this chasm.  If what you proposed was that all ASF software could be utilized by users under
the AL and had no additional encumbrances, but you wanted (as suggested in threads long ago)
to combine an external non-AL encumbered work to make something larger than what ASF software
alone can provide, that might be very welcome.  The ASF producing software that can only be
used with additional encumbrances runs counter to the founding of organization, even as you
advocate for this to change.  Because this is not a legal argument, but a policy argument,
I'm not sure whether legal-discuss is the obvious forum to change the purpose of the foundation.


Mime
View raw message