> We would publish these apps using the Apache License 2.0, as all other Dropwizard projects do. Not apps, libraries. :)
On Monday, April 29, 2019 at 4:49:33 PM UTC-7, mza...@apple.com wrote: > > Hey Jochen! > > > > Do you have a list and description of the modules you're planning to > open-source? > > We do! > > > So we have three modules that we think make sense to live in the core > Dropwizard project. Two of which are in a pretty ready state to be > contributed, but because 2.0.0 is already in RC stage, might not make sense > until that ships. > > > The ones we have are: > > > > - A module containing a bundle that allows for configuration of > various headers that are important for services that are accessed by web > browsers. This includes: HTTP Strict Transport Security (HSTS), > X-Frame-Options, X-Content-Type-Options, X-XSS-Protection (XSS), Content > Security Policy (CSP), and Cross-Origin Resource Sharing (CORS). > - A module containing a more-feature rich and extendable admin page, > in short. This would need a little bit more work before we could > contribute > it, because there’s some cleanup work we’d need to do, and some changes to > make it more flexible in how it’s used. > - A bundle containing improved health check functionality. Provides > functionality to allow a user to associate a schedule with any registered > health checks to run on a recurring basis, and to allow marking which > checks are critical to service health (i.e., if a dependency is down, it > should bring the service down with it). The bundle then allows exposing > another health check URL on the server port, which simply returns the > aggregated view of the application’s health, rather than trigger checks on > every health check. > > > We also have some additional potential contributions that we don’t think > would make sense to live in the core Dropwizard project, but rather > (hopefully) could live in the Dropwizard organization. Our reasoning for > including these would be that we already maintain these internally, and > keep them up to date with the underlying client libraries we’re wrapping, > AND we do so in a consistent way, so we figured it might make sense to > broaden the audience for these, as there’s no good reason not to. > > > > - A module providing integration with Kafka. > - A module providing integration with Redis. > - A module providing integration with Cassandra. > - A module providing integration with FoundationDB. > > > There may be some others I’m missing here, that we may propose down the > line, but this should be the majority of what we’d like to publish > initially. > > > > Also, what license are they currently under or which licenses do you > plan to use for them? All projects under the Dropwizard umbrella are using > the Apache License 2.0. > > Are there any other things to consider copyright- or license-wise when > you're contributing these modules? > > > We would publish these apps using the Apache License 2.0, as all other > Dropwizard projects do. > > > > And finally, do you plan to keep contributing to the modules you're > going to open-source or will it be more or less a "code drop" without any > further involvement? > > > We plan to keep contributing to the modules we contribute. We maintain > these internally on an ongoing basis already, so we’d just continue to do > so. > > On Sunday, April 28, 2019 at 2:23:09 PM UTC-7, Jochen Schalanda wrote: >> >> Hi Michael, >> >> Thanks for reaching out! >> >> Depending on the specific modules, it might make sense to adopt them in >> the Dropwizard organization on GitHub. Alternatively, you can also host >> them in your own accounts and add them to the module directory at >> https://modules.dropwizard.io/, as Nick described in his last email. >> >> Do you have a list and description of the modules you're planning to >> open-source? >> >> Also, what license are they currently under or which licenses do you plan >> to use for them? All projects under the Dropwizard umbrella are using >> the Apache License 2.0. >> Are there any other things to consider copyright- or license-wise when >> you're contributing these modules? >> >> And finally, do you plan to keep contributing to the modules you're going >> to open-source or will it be more or less a "code drop" without any further >> involvement? >> >> >> Best regards, >> Jochen >> >> Am 27.04.2019 um 23:14 schrieb mzamani via dropwizard-dev < >> dropwiz...@googlegroups.com>: >> >> Hey dropwizard-dev, >> >> We've got some modules we'd like to open source that we use internally at >> Apple. Some of those might make sense to be included in the core Dropwizard >> project, but others definitely don't, and it would make much more sense to >> have them live outside of the Dropwizard repo. >> >> We're hoping we might be able to contribute these to the Dropwizard >> organization (https://github.com/dropwizard) instead, as that seems like >> a place where it would make sense for Dropwizard extensions to live. >> However, we wanted to consult you guys to see if you had any strong >> preferences one way or another, or if there's any process we should be >> aware of in order to add a project to the Dropwizard GitHub organization. >> >> It might be worth mentioning that it would be easier for us to open >> source them if they can live in the Dropwizard organization, rather than a >> brand new spot, due to how our corporate open source policy works. >> >> Thanks! >> >> -- You received this message because you are subscribed to the Google Groups "dropwizard-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
