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.
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 sectionthat 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
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.
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.
The policy does suggest that source under a reciprocal license should beclearly 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" asopposed 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.-DavidThose issues aside, my opinion is that including the EPL licensed codeis 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 [email protected] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
smime.p7s
Description: S/MIME cryptographic signature
