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: Apache License v2.0
Date Sat, 27 Sep 2008 19:58:51 GMT
Arthur Tam asked:
> 
> However, back to my question
> 
> is why Apache License v2.0 doesn't require Licensor open the source in
> the *stated way* but still approved by OSI. It seems the Apache License
> not comply with OSD #2. Why I'm start this thread is because SpringSource
> new maintenance policy. I just wonder SpringSource has no obligation to
> release the fixes/patches along with source code after the "free" period
> base on Apache License v2.0 that you can access by some means (although
> somebody say they will release the fixes in source code somewhere)

Although Larry's answer was 100% correct, I suspect Arthur is asking a very
different question, and that answer is no.  Neither the AL does nor the GPL
requires what you are asking about, above.  Let's dissect what can happen
from source code X to source code Y.

First, with AL or GPL, if you modify the sources for your use, you are not
required to give your modifications to anyone, period.  That's never been
a consideration of OSI designation, except a guarantee that you are free
to make such modifications.

If you modify the sources and redistribute them, the AL and GPL diverge.
In the AL case, you may give them the sources, you are not required to, and
you can simply deliver a binary and the license does not compel you to
deliver the sources of that binary.  The GPL, on the other hand, compels
you to provide that source **downstream** to any users of your modified
source code.  The GPL, as I mention in the paragraph above, does not
require you to distribute your modifications upstream.  Again, all the OSI
license says in this respect is that you have a guarantee that you may
redistribute your modifications.

Neither the AL nor the GPL require the original author to share future
versions of the software under the same license.  The author/copyright
holder may offer future versions under the same license, a different
license, or even as closed source.  Nothing in any OSI approved license
compels the author to do something in future versions of the work.  That
said, the version in your hands under a specific license remains licensed
to you under that original license.

The GPL does require that future work that contains contributions of
others (additional copyright holders) retains the terms of the GPL,
including provision for downstream users to obtain the source code.
So a work can only become other-than-GPL if *all* copyright licensors
agree to offer another license, or if their individual contributions
to the work is already dual licensed under other compatible licenses.

No OSI license compels the author to "release the fixes/patches along
with source code", and I doubt such a license would ever gain traction
among authors.  It essentially voids the "No Warranty" clause in virtually
every OSI license.  As far as I know, no OSI license today requires the
author to release binary fixes/patches ever.  OSI approved licenses are
written with respect to the source code itself.

However, if an Open Source author offers you a binary-only fix or patch
with no sources, you simply would not call that Open Source now, would you?
That simply means that closed source work they handed you is not open source.
And if they continue to "release the fixes in source code somewhere", then
it appears, this remains open source in the first place.

I'm guessing this is a social/cultural difference between Java users and
other open source users.  Many open source users have never expected to
be handed binaries, although it's convenient when we get them.  Often open
source projects deliver no binaries at all.

The gist of Arthur's question around SpringSource comes down to an apparent
core belief within the Java community that open source licenses convey a
.jar file to them.  The confusion's origin is that the .java source code
work is the open source licensed work, the compiled .jar is a derivative
product (and most often, doesn't contain source at all).  This has even
been a point of confusion for ASF projects, who had often voted to release
a .jar, whereas the ASF "releases" only source code.

Larry and OSI gurus, I look forward to correction of any misinformation
in the comments above.  Usual disclaimers: I am one of 9 directors of the
Apache Software Foundation, also a SpringSource employee, and I am speaking
on behalf of neither organization.  These comments above are entirely my own,
and are hopefully productive.

Yours,

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


Mime
View raw message