Inline...
From: "Scott Gray" <
[hidden email]>
> 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
>>>
[hidden email]
>>> 214-720-0700 x 315
>>> Brainfood, Inc.
>>>
http://www.brainfood.com>>>
>>
>
>
Locked
