On May 31, 2014, at 7:31 AM, Ankesh Anand wrote:
> This may be what their intention is, but it is not what their license terms
> actually state. This is a common incorrect interpretation that open source
> use is not a commercial use. Especially under US law (and most jurisdictions
> that come to mind), it very much is a commercial activity, even if no money
> is involved (but money could be involved too). CC-BY-NC is a no-go.
>
> If they are okay with open source projects using their charts, then they
> should state that (by licensing under a standard open source use license like
> CC-BY or even GPL).
>
> Thanks for the clarification. I thought if we had a go-ahead from them, then
> we could use it but I was clearly wrong.
Not wrong, just an e-mail saying they think their existing CC-BY-NC license
applies to our situation is not sufficient (because it's incorrect). They'd
need to make an explicit unrestricted license grant from someone legally able
to make that statement. You're not likely going to get an official statement
like that quickly.
While we've gone through that hassle in the past with other groups, but it
really seems unnecessary and perhaps even undesirable for something like this
where there are many suitable open source and free software alternatives. Even
when they're alternatives that are not as popular or even as good feature-wise,
it's in our long-term better interest to consider them first, consider
implementing something better (that is open source) second, and only
considering the commercial offerings last (and at great hesitation).
Open source software development is often not just about getting features
implemented. There is a philosophy and morality behind different projects
(usually presented in license terms) and our preference must be towards our
long-term objectives. My apologies that you got as far as you did before we
got to have this discussion. Hopefully your code is modular enough that it'll
be easy to hook in another API without too much effort. If not, that might be
something worth investing some development effort towards in case we want to
use something different down the road.
> Moving to a different library should not be a problem but my only concern is
> it would push back the schedule by a few days. I am done with the initial
> charts using HighCharts.js, and migrating them might take some time, so
> please be patient. :)
This is fine.
> I will look into the other libraries again and try to pick an alternative as
> soon as possible.
Please share what alternative you're picking (including whatever rationale,
criteria, spreadsheet, or decision matrix you're using to decide) before you
invest time using it (this goes for all new GSoCers and existing devs alike).
Adopting new external dependencies should always be presented to the community
for discussion as we all will bear the long-term maintenance cost.
Cheers!
Sean
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
