Re: svn commit: r890175 [1/2] - in /ofbiz/trunk: ./ applications/content/ applications/content/data/ framework/ framework/base/config/ framework/birt/ framework/birt/config/ framework/birt/data/ framework/birt/data/helpdata/ framework/birt/lib/ framework/b...

[Adam Heath-2]

[hidden email] wrote:
> Author: hansbak
> Date: Mon Dec 14 04:41:28 2009
> New Revision: 890175
>
> URL: http://svn.apache.org/viewvc?rev=890175&view=rev
> Log:
> Merge birt branch 831204:886087 and 831209:885099. A contribution by Antwebsystems employee Chattree

It's not apparent from the diff sent to this list, but this commit has
license issues; namely, thet jsps are back.

Additionally, .classpath hasn't been updated.

[hans_bakker]

We will either remove or replace all jsp's wih ftl's of the birt
component in the next few days...

Regards,
Hans


On Mon, 2009-12-14 at 10:19 -0600, Adam Heath wrote:

> [hidden email] wrote:
> > Author: hansbak
> > Date: Mon Dec 14 04:41:28 2009
> > New Revision: 890175
> >
> > URL: http://svn.apache.org/viewvc?rev=890175&view=rev
> > Log:
> > Merge birt branch 831204:886087 and 831209:885099. A contribution by Antwebsystems employee Chattree
>
> It's not apparent from the diff sent to this list, but this commit has
> license issues; namely, thet jsps are back.
>
> Additionally, .classpath hasn't been updated.

--
Antwebsystems.com: Quality OFBiz services for competitive rates

[Ean Schuessler]

I'm not clear whether that solves the problem (and it is, indeed, a very
silly problem). The problem is that an FTL file would still be in
"source form" and that is where the issue is. We could have an even
sillier argument about whether and FTL file is "Turing complete" and,
therefore, data or code. I sure don't want to do that.

I prefer Adam's suggestion that we compress the JSPs into a WAR and
claim that they are a "binary" in that state. I strongly suspect that we
will never hear a complaint from IBM on the matter and our action of
building the WAR would demonstrate a good faith effort to comply with
their license.

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

[Tim Ruppert]

+1 - that makes great sense Ean - thanks for laying it out like a towel.

I have a question about this legal stuff - does only having licensing issues in the repo for a little bit count any less against us?  Does it actually open us up to anything in any way?  I really don't know the answer, so I'd love to here other thoughts on the topic.  

I'm assuming that as soon as it's checked in, we're screwed, which means to me that we must do better at not to putting them into the repo at all - instead of cleaning them up in the future as this has happened numerous times on this effort.  Anyways, any info on the matter would help me - so thanks in advance.

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Dec 16, 2009, at 5:24 PM, Ean Schuessler wrote:

> I'm not clear whether that solves the problem (and it is, indeed, a very
> silly problem). The problem is that an FTL file would still be in
> "source form" and that is where the issue is. We could have an even
> sillier argument about whether and FTL file is "Turing complete" and,
> therefore, data or code. I sure don't want to do that.
>
> I prefer Adam's suggestion that we compress the JSPs into a WAR and
> claim that they are a "binary" in that state. I strongly suspect that we
> will never hear a complaint from IBM on the matter and our action of
> building the WAR would demonstrate a good faith effort to comply with
> their license.
>
> 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
>

[Ean Schuessler]

Like most legal things I think its a question of intent. Debian has
certainly had many situations where there were "problems" in the repos
and past releases that remain uncorrected. Sometimes the legal questions
are very fuzzy and sometimes people just aren't aware that there is a
problem. If its clear that you are trying to address problems then you
are in a much better position than if you are clearly and willfully
disregarding the terms of someone's license.

I think we have to accept, as a matter of course, that we are going to
have problems sneak into the repo. Removing a revision from SVN is
extraordinarily difficult and *any* user of SVN is going to have that
problem. I think, for our purposes, we can regard SVN as a development
tool and not a distribution tool (though that's not exactly true its a
question of intent and common industry practices). We should make a real
effort to not knowingly include glaring license problems in an official
release.

With all these things, remember IANAL (I Am Not A Lawyer) but I have
been around Debian for a while and its a veritable cornucopia of
licensing squabbling... for what that's worth.

Tim Ruppert wrote:
> +1 - that makes great sense Ean - thanks for laying it out like a towel.
>
> I have a question about this legal stuff - does only having licensing issues in the repo for a little bit count any less against us?  Does it actually open us up to anything in any way?  I really don't know the answer, so I'd love to here other thoughts on the topic.  
>
> I'm assuming that as soon as it's checked in, we're screwed, which means to me that we must do better at not to putting them into the repo at all - instead of cleaning them up in the future as this has happened numerous times on this effort.  Anyways, any info on the matter would help me - so thanks in advance.
>  
--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[Tim Ruppert]

Thanks man - much appreciated.

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Dec 16, 2009, at 6:32 PM, Ean Schuessler wrote:

> Like most legal things I think its a question of intent. Debian has
> certainly had many situations where there were "problems" in the repos
> and past releases that remain uncorrected. Sometimes the legal questions
> are very fuzzy and sometimes people just aren't aware that there is a
> problem. If its clear that you are trying to address problems then you
> are in a much better position than if you are clearly and willfully
> disregarding the terms of someone's license.
>
> I think we have to accept, as a matter of course, that we are going to
> have problems sneak into the repo. Removing a revision from SVN is
> extraordinarily difficult and *any* user of SVN is going to have that
> problem. I think, for our purposes, we can regard SVN as a development
> tool and not a distribution tool (though that's not exactly true its a
> question of intent and common industry practices). We should make a real
> effort to not knowingly include glaring license problems in an official
> release.
>
> With all these things, remember IANAL (I Am Not A Lawyer) but I have
> been around Debian for a while and its a veritable cornucopia of
> licensing squabbling... for what that's worth.
>
> Tim Ruppert wrote:
>> +1 - that makes great sense Ean - thanks for laying it out like a towel.
>>
>> I have a question about this legal stuff - does only having licensing issues in the repo for a little bit count any less against us?  Does it actually open us up to anything in any way?  I really don't know the answer, so I'd love to here other thoughts on the topic.  
>>
>> I'm assuming that as soon as it's checked in, we're screwed, which means to me that we must do better at not to putting them into the repo at all - instead of cleaning them up in the future as this has happened numerous times on this effort.  Anyways, any info on the matter would help me - so thanks in advance.
>>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>

[hans_bakker]

Hi Ean,
That would be really nice if you could make it possible to install WAR
files not only for Birt but possibly for other systems too like ESME
and CAS (Single sign on) If we could automate that and make it an ant
task that would be really cool....

Many people will be happy that these system are not distributed with
OFBiz but still  can be installed pretty automated....

On Wed, 2009-12-16 at 18:24 -0600, Ean Schuessler wrote:

> I'm not clear whether that solves the problem (and it is, indeed, a very
> silly problem). The problem is that an FTL file would still be in
> "source form" and that is where the issue is. We could have an even
> sillier argument about whether and FTL file is "Turing complete" and,
> therefore, data or code. I sure don't want to do that.
>
> I prefer Adam's suggestion that we compress the JSPs into a WAR and
> claim that they are a "binary" in that state. I strongly suspect that we
> will never hear a complaint from IBM on the matter and our action of
> building the WAR would demonstrate a good faith effort to comply with
> their license.
>
> Hans Bakker wrote:
> > We will either remove or replace all jsp's wih ftl's of the birt
> > component in the next few days...
> >  

--
Antwebsystems.com: Quality OFBiz services for competitive rates

[Ean Schuessler]

Is there any reason we cannot deploy these WARs via Tomcat?

Hans Bakker wrote:
> That would be really nice if you could make it possible to install WAR
> files not only for Birt but possibly for other systems too like ESME
> and CAS (Single sign on) If we could automate that and make it an ant
> task that would be really cool....
>
> Many people will be happy that these system are not distributed with
> OFBiz but still  can be installed pretty automated....
>  
--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[hans_bakker]

We never looked into that possibility assuming we needed to do too much
adaptation after deploying. But be my quest, if you think it is
possible.

On Wed, 2009-12-16 at 20:37 -0600, Ean Schuessler wrote:

> Is there any reason we cannot deploy these WARs via Tomcat?
>
> Hans Bakker wrote:
> > That would be really nice if you could make it possible to install WAR
> > files not only for Birt but possibly for other systems too like ESME
> > and CAS (Single sign on) If we could automate that and make it an ant
> > task that would be really cool....
> >
> > Many people will be happy that these system are not distributed with
> > OFBiz but still  can be installed pretty automated....
> >  

--
Antwebsystems.com: Quality OFBiz services for competitive rates

[Ean Schuessler]

Out of curiousity, I dropped an unadulterated (but unpacked) copy of the
BIRT viewer WAR into an OFBiz component and put it in hot-deploy and it
worked right out of the box! I'm sure some of this is due to work you
have been doing in trunk to take care of compatibility issues but,
still, its interesting. I even copied in some JDBC based reports I have
written against OFBiz tables and they worked without any issues as well.

The main questions are, how would we get OFBiz data into an unmodified
BIRT WAR? I know there are several vehicles available within BIRT to
allow this, we would just have to determine what is the easiest thing to
get going. If we had some IOC (ie. Spring) style features in the OFBiz
container this might be one way to achieve the desired result.

Adam has been working (successfully) to create a SQL front-end to the
entity engine to allow typical business users to leverage their SQL
skills while still gaining the benefits in the EntityEngine. We have
discussed (and he is building) a JDBC adapter class that will sit on
these facilities. If this JDBC driver were to communicate with the OFBiz
instance we might be able to provide a facility where you use something
like "org.ofbiz.jdbc.Driver" as the BIRT driver and a JDBC url like
"jdbc:ofbiz:default" to get a connection to the default delegator.
Queries would work naturally as if you were talking directly to the
database but retain portability, caching, views and other OFBiz features.

Hans Bakker wrote:
> We never looked into that possibility assuming we needed to do too much
> adaptation after deploying. But be my quest, if you think it is
> possible.
>  
--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[Scott Gray-2]

Hi Hans,

Regardless of the final solution to this problem, the offending birt  
code should be removed from the trunk as soon as possible and not be  
left until the solution is ready.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com


On 17/12/2009, at 3:46 PM, Hans Bakker wrote:

> We never looked into that possibility assuming we needed to do too  
> much
> adaptation after deploying. But be my quest, if you think it is
> possible.
>
> On Wed, 2009-12-16 at 20:37 -0600, Ean Schuessler wrote:
>> Is there any reason we cannot deploy these WARs via Tomcat?
>>
>> Hans Bakker wrote:
>>> That would be really nice if you could make it possible to install  
>>> WAR
>>> files not only for Birt but possibly for other systems too like ESME
>>> and CAS (Single sign on) If we could automate that and make it an  
>>> ant
>>> task that would be really cool....
>>>
>>> Many people will be happy that these system are not distributed with
>>> OFBiz but still  can be installed pretty automated....
>>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive rates
>

[Ean Schuessler]

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.

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.

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

[Ean Schuessler]

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

One other noteworthy fact is that JUnit (which we use and don't think we

have any intention of removing) is also under the CPL.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[David E. Jones-2]

Thanks for your comments Ean, this is a voice of sanity IMO....


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.

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.

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

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

[Scott Gray-2]

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


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

[David E. Jones-2]

On Dec 18, 2009, at 3:03 PM, Scott Gray wrote:

> On 19/12/2009, at 9:44 AM, David E Jones wrote:
>> 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.

I'm not into shouting into the wind any more. I used to be, but not any more. That's why I won't try to argue this one either. Eventually people will tire of fighting, and then something will happen. I'm perfectly willing to wait.

-David

[Scott Gray-2]

On 19/12/2009, at 10:09 AM, David E Jones wrote:

>
> On Dec 18, 2009, at 3:03 PM, Scott Gray wrote:
>
>> On 19/12/2009, at 9:44 AM, David E Jones wrote:
>>> 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.
>
> I'm not into shouting into the wind any more. I used to be, but not  
> any more. That's why I won't try to argue this one either.  
> Eventually people will tire of fighting, and then something will  
> happen. I'm perfectly willing to wait.

I'm sending an email to legal-discuss now.  The frustrating thing from  
my point of view is that this was discussed and the code of concern  
was subsequently removed from the branch but then added back in when  
BIRT came into the trunk.  An email to legal-discuss should have been  
sent over a month ago and I don't think it was my responsibility to do  
so.

Regards
Scott

[David E. Jones-2]

On Dec 18, 2009, at 3:23 PM, Scott Gray wrote:

> On 19/12/2009, at 10:09 AM, David E Jones wrote:
>
>>
>> On Dec 18, 2009, at 3:03 PM, Scott Gray wrote:
>>
>>> On 19/12/2009, at 9:44 AM, David E Jones wrote:
>>>> 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.
>>
>> I'm not into shouting into the wind any more. I used to be, but not any more. That's why I won't try to argue this one either. Eventually people will tire of fighting, and then something will happen. I'm perfectly willing to wait.
>
> I'm sending an email to legal-discuss now.  The frustrating thing from my point of view is that this was discussed and the code of concern was subsequently removed from the branch but then added back in when BIRT came into the trunk.  An email to legal-discuss should have been sent over a month ago and I don't think it was my responsibility to do so.

Yes, I agree with you there Scott. Hans or Adam should have researched and resolved legal questions before committing.

Also, while I haven't looked at the code, I thought I saw somewhere that some of the EPL licensed JSP files were modified, and that would certainly not be allowed and should be removed (and some wants the files they should be clean room rewritten or something if changes are needed in order to avoid the copyright and licensing issues).

-David

[Adam Heath-2]

David E Jones wrote:
> Yes, I agree with you there Scott. Hans or Adam should have researched
> and resolved legal questions before committing.

The person committing the code is responsible for making certain it
follows licensing guidelines.  Please refer back to the SCA that we
all had to sign before becomming a committer.

If you aren't willing to follow those guidelines, then you shouldn't
be committing code.

[Ean Schuessler]

Scott Gray wrote:

> 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 suppose it depends on what you decide is a "more substantial" amount

of code. Is the limit 34K? (the size of the example DTD) That seems
arbitrary to me. The .js, .jsp and .css files, taken together constitute
1.7% of the BIRT runtime, and they are uncompressed. That seems fairly
insubstantial to me but I suppose we must at this point defer to higher
authorities.

It does seem crystal clear that including the BIRT runtime as a WAR is
in compliance because it "reduces the exposed surface area" of the code.
If they want to split that hair I suppose we can go that way or write a
ROT13 decoder to strap onto the JSP resource loader.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com