Picking this thread back up. On the code in the vendors folder, do we know where that came from? If it was not contributed to Superset we need to 1) check that it's ok to have it at all (ie, we have the author's blessing); 2) figure out what license the author released it under; 3) put the license and copyright information in the LICENSE and NOTICE files.
Same questions apply for code in the visualizations folder. With just a quick look through there I didn't see any licenses, notices, copyright statements, etc. A few other things I noticed: You need a NOTICE file at the top of the source directory, see https://incubator.apache.org/guides/releasemanagement.html and http://www.apache.org/legal/release-policy.html You need a DISCLAIMER file, see https://incubator.apache.org/guides/branding.html None of the source files appear to have Apache headers on them. I didn't find a header in any of the css, html, py, js, sh, or yaml files. I'm not saying these are the only file types that should have them, they're just the ones I checked. Any non-binary file that can take comments should have the header. (By header I mean the "Licensed to the Apache Software Foundation..." bit, which you can find in any Apache project's code. Other than the image files, I didn't see any binary or executable files, which is good. There might be other issues, but this will be a good start. Alan. On Fri, Oct 26, 2018 at 12:49 PM Maxime Beauchemin < maximebeauche...@gmail.com> wrote: > Super. This clarifies things for me. If it's a source only release, then we > have MUCH LESS concerns. Some things to check are: > * This vendors folder > < > https://github.com/apache/incubator-superset/tree/master/superset/assets/vendor > >, > files in here are copied & modified > * parallel-coordinates: > https://github.com/syntagmatic/parallel-coordinates/blob/master/LICENSE > (what license is this?) > * cal-heatmap: > https://github.com/wa0x6e/cal-heatmap/blob/master/LICENCE-MIT (MIT) > * pygment.css: https://github.com/nex3/pygments/blob/master/LICENSE > (BSD2 <https://github.com/nex3/pygments/blob/master/LICENSE(BSD2>) > * the visualization folder > < > https://github.com/apache/incubator-superset/tree/master/superset/assets/src/visualizations > > > has some copied/modified code as well, mostly coming from bl.ocks.org . I > believe there should be headers in all cases as to where it came from. We > probably need to dig in here. Good news is that there's ongoing work to > ship all visualizations as plugins, so that we can keep this out of the > source releases. > > Max > > On Fri, Oct 26, 2018 at 11:22 AM Alan Gates <alanfga...@gmail.com> wrote: > > > Responses inlined. > > > > On Fri, Oct 26, 2018 at 8:57 AM Maxime Beauchemin < > > maximebeauche...@gmail.com> wrote: > > > > > One of the main challenge/blocker to date has been around crafting our > > > LICENSE.txt file, and keeping it up to date as our JS dependency tree > is > > > massive, deep and very dynamic. It seemed like we have to do this > > > programmatically. I started writing a script to do so a little while > back > > > and was looking for more mentor guidance as to how to handle the > special > > > cases. There are many libs under "MIT*" or "BSD*" where the "*" needs > to > > be > > > investigated and personally I'm not qualified to know whether "MIT with > > > LLVM clause" is ok or not... So while I can commit time to this, I can > > only > > > raise questions in the process. Also there have been questions around > > > convenience releases and whether it's ok to have grey-zone license if > > > they're fetched at build time. We need mentor and legal guidance here. > > > https://github.com/apache/incubator-superset/pull/5801 > > > > > > Sorry if this is repetitive as I'm new here, but step 1 should be doing a > > source release. Apache doesn't do binary releases, it does convenience > > binaries. If the convenience binary isn't 100% Apache approved yet, > we'll > > solve that in a step 2. > > > > For the source release I'm guessing that all the JS stuff doesn't get > > pulled in, is that right? If so, then we can proceed to the first phase > > and get an Apache release out. And we can post those convenience > binaries > > in their current messy state. Then we'll start working on getting the > > licensing and packaging right for those. > > > > > > > > > > I also have filled in the "The Apache Project Maturity Checklist" last > > > month in the GH issue bellow, and it seems like we're doing fairly > well: > > > https://github.com/apache/incubator-superset/issues/5951 > > > > > > I believe that the issues around having discussions off-lists can be > > > addressed easily, but we need to clarify what's acceptable or not. Is > > Slack > > > ok? Are in-person operational community meetings ok if everyone is > > welcomed > > > to attend, minutes are posted and no important decisions are taken? > > > > > > > The key in Apache is "if it didn't happen on the lists, it didn't > happen". > > Anything that copies to the lists (JIRA, GitHub, etc.) counts. Obviously > > people are going to have f2f, slack, etc. discussions. The key is to > > always report the content of those discussions and allow those on the > list > > to be part of the discussion and decision making process. The issue with > > any realtime tool like slack is that no matter what time of day you pick, > > it's 3am somewhere, which makes it hard to build a geographically > > distributed community. > > > > Let me give an example of how we handle this in the Hive community. > Since > > many Hive developers work for either Cloudera or Hortonworks, obviously a > > lot off list discussion happens. But _no_ changes are made without a > > JIRA. And a JIRA patch must be up for 24 hours before anyone can commit > > it. This way everyone has a chance to take a look at it before it's > > committed, even if the initial idea for the change is based on some > hallway > > conversation somewhere. Superset will probably prefer git to JIRA, but > the > > same principles apply if you let any PR stay open for 24 hours before > > merging it. > > > > > > > > > > Personally I'm committed to align with "the Apache Way" and do a > > > significant portion of the work that we have to do in order to > graduate, > > > but I would love support and help from committers and mentors to make > it > > > happen. > > > > > > > Glad to hear you're committed. We mentors are here to help. If we have > a > > first pass of what a source release looks like I can take a look and give > > some feedback. > > > > Alan. > > >
