Based on the marketing guidelines a certain company is now using for a different Apache project, I think the simplest way to avoid issues would be to include a trademark disclaimer on pages including the name log4net as well as making sure to call it "Apache log4net" in titles and such. A disclaimer noting that third party plugins are not officially endorsed by or managed by Apache or something like that.
On 1 May 2018 at 11:12, Dominik Psenner <[email protected]> wrote: > Thanks for sharing this idea! I'm a great fan of this. Please do not > misunderstand my late response, lately spare time has become really rare, > sorry. Further I hope that in the near future, we may decide to split up > log4net into multiple packages. This trend can be observed about > everywhere, also log4j2, which is where log4net originally came from. To > make this plan more concrete, let me note that I envision something like: > > log4net > log4net.Appenders.File > log4net.Appenders.Console > log4net.Appenders.AdoNet > log4net.Appenders.MQTT > [...] > > This allows to keep only very few dependencies of the log4net core library, > allowing to become the core library as portable and backwards compatible as > possible. Such a structure further indicates a usecase for multiple places > for an .Extensions prefix open to third party contributors: > > log4net.Extensions (this could be a place for generic interfaces to > frameworks like asp.net core, more log event filters, ..) > log4net.Appenders.Extensions (this could be a place for more appenders, > i.e. the previously mentioned MQTT, ..) > > Is this something that the community would like to see happen? > > I'm however unsure where there would arise trademark issues. Package names > are more like namespaces. So long the extensions do not claim to be part of > the ASF, it should be fine. Even on the contrary. Clearly defined rules and > conventions create room for transparency on what comes from where. > > Please note further that if we decide to reserve all prefixes, we will need > to find a solution for all the existing packages that match the pattern > log4net* and this involves a bit of communication with the package > maintainers. For instance, all existing extensions to log4net would have to > be renamed. A hypothetical log4net.foobar extension would have to be > renamed to log4net.Extensions.foobar or log4net.Appenders.foobar if the > extension was only about an appender that supports foobar. This could also > be a great opportunity to attract the developers of the extensions to > become more involved with the community behind log4net here at apache. I > feel that this is something that the .net part of the apache logging family > really needs. > > On 29 Apr 2018 8:32 p.m., "Matt Sicker" <[email protected]> wrote: > > It certainly sounds like a good idea. As for sub prefixes, that's an > interesting question because there would be Apache trademark issues there > potentially, though I'm not entirely sure about that and would need to > investigate further. > > > On 28 April 2018 at 00:27, Sean Rose <[email protected]> wrote: > > > Now that NuGet has package ID prefix reservation ( > > https://docs.microsoft.com/en-us/nuget/reference/id-prefix-reservation) > > are there plans to reserve the log4net.* prefix? > > > > If so, will a particular sub prefix be left available for community > > created packages? > > > > For example: > > - log4net.Community.* (like AutoFixture, https://github.com/ > > AutoFixture/AutoFixture/issues/863) > > - log4net.Contrib.* (like SpecFlow, http://specflow.org/2017/ > > nuget-packages-reserved-id-naming-conventions/) > > - log4net.Ext.* (like some existing packages, > https://www.nuget.org/ > > packages?q=log4net.Ext) > > - log4net.Extensions.* (like some existing packages, > > https://www.nuget.org/packages?q=log4net.Extensions) > > > > Thanks, > > Sean Rose > > > > > -- > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
