Inline...
From: "Scott Gray" <scott.g...@hotwaxmedia.com>
On 19/12/2009, at 9:44 AM, David E Jones wrote:
Thanks for your comments Ean, this is a voice of sanity IMO....
If there is any doubt or disagreement the only sane thing to do is to ask
legal, anything else is just noise.
So who will ask ?
I'm not sure to understand why they use "may" in these sentences instead of
must?
IANAL and English is not my mother tongues, any ideas?
On Dec 18, 2009, at 1:46 PM, Ean Schuessler wrote:
I have done some more reading on Apache 3rd party licensing and after
some careful reading, I believe that Hans' use of BIRT is acceptably
within the policy. The latest copy of the policy is available at
"http://www.apache.org/legal/3party.html"; with the key area being
"Category B: Reciprocal Licenses". The important phrase in that section
that we seem to have missed is the reference to code "not directly
consumed at runtime in source
<http://www.apache.org/legal/3party.html#define-source> form". To me,
that phrase says that source which is "consumed at runtime in source
form" is not required to be shipped as a binary.
Selective quoting FTW?
"For small amounts of source that is directly consumed by the ASF product at runtime in source form, and for which that source is
unlikely to be changed anyway (say, by virtue of being specified by a standard), this action is sufficient. An example of this is
the web- facesconfig_1_0.dtd, whose inclusion is mandated by the JSR 127: JavaServer Facesspecification.
Code that is more substantial, more volatile, or not directly consumed at runtime in source form may only be distributed in
binary form."
Small amount of source? I don't consider an entire 45 file javascript library
and 37 jsp files to be a small amount of source.
Unlikely to be changed? The javascript perhaps but I think there is a decent
chance of a downstream user changing the jsp files
As long as s/he does not distribute her/his work it's not a problem.
But ok, it's possible and then it breaks reciprocity: <<requiring that the distribution of modifications or derivative works be made
available under the same license as the original work>>
I agree with this and tried to make this point early on in the discussion. We should be able to include these files just fine in
source form, as long as they are not modified.
Mmm, we let open the possibibilty to break reciprocity, isn'it ?
You didn't try very hard, I responded to you and you didn't reply.
For any that need to be modified we would need to do a "clean room" style implementation. Coding it in a different language, or
templating tool, even using the same concepts as the original, is fine AFAIK as there is no violation of copyright possible then
(same ideas, substantially different implementation).
For EPL code we can call it and refer to it, but not change it without having to license the changes as EPL as well (ie it is
not viral by reference/use, only by change).
"We" being the community at large, the primary concern of the policy is how these licenses will affect downstream users, hence
the restrictions on including source code that can be modified. While we all seem to understand the implications of modifying
EPL source code there is a good chance that our users will not.
Right, and it's clearly our responsability
Jacques
The policy does suggest that source under a reciprocal license should be
clearly marked as such, primarily to avoid it (or dependencies on it)
being intermingled with other ASL code. I think that since BIRT is
packaged as its own component we are well on the way to this. We may
just want to consider whether this code belongs in "framework" as
opposed to "applications" or "specialpurpose". At the least, we should
include a NOTICE-BIRT-IS-EPL file or something at the root of the component.
Where to put it is another good point. IMO if we're going to have OOTB reports using it then it probably should go in the
framework. If not, then specialpurpose is probably best.
-David
Those issues aside, my opinion is that including the EPL licensed code
is legitimate.
Hans Bakker wrote:
We will either remove or replace all jsp's wih ftl's of the birt
component in the next few days...
--
Ean Schuessler, CTO
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
