On Thu, Aug 6, 2015 at 1:29 AM, Jochen Theodorou <blackd...@gmx.org> wrote: > Am 06.08.2015 08:22, schrieb Niclas Hedhman: >> >> On Thu, Aug 6, 2015 at 8:43 AM, Roman Shaposhnik <ro...@shaposhnik.org> >> wrote: >> >>> I honestly see no problem with that, again provided that the artifact can >> >> NOT >>> >>> be confused with the one coming from Apache project. >> >> >> I think the "problem" lies in Trademarks. Debian's Tomcat7 is labeled >> "Servlet and JSP engine" and its Tomcat8 is labeled "Apache Tomcat 8 - >> Servlet and JSP engine", yet I don't see Apache Tomcat project >> creating/maintaining a Debian dist. >> >> Now, is Debian allowed to call it "Tomcat"? Is it allowed to call Tomcat8 >> to BE "Apache Tomcat8", when in fact(!) there are changes to the source, >> such as the start script in Debian Tomcat is not original of Apache >> Tomcat, >> but instead follows a Debian template for how those scripts should be >> written. I am not sure what all the changes are, feel free to check; >> http://anonscm.debian.org/cgit/pkg-java/tomcat8.git/tree/debian/patches >> >> IF (like Mozilla) Apache decides to strike down on Debian and not allowing >> it to use the same names, _I_ think it is a disservice to the users >> (IceWeasel browser), but as it stands, Apache trademark licensing seems to >> not really be followed (Perhaps Debian has some permission that was >> granted >> long in the past... I may have missed that). > > > I think there is nothing in the apache license 2 forbidding the usage of the > project name or even apache (version 1.1 and 1 have been different and did > indeed require a permission). The trademark weapon is more one of last > resort. For example to go against false releases with malicious code added > and the distributor not willing to take it of the web. > > At least I hope no-one has some crazy idea as that ;)
Once again: this has *nothing* to do with the code (and only code is covered by ALv2) and everything to do with brand management policy. You can take Groovy source code and build Jochenoovy without any problem whatsoever, the issue is when *you* not the PMC want to build Groovy and start distributing it in parallel with the actual artifact. Thanks, Roman. P.S. As a tangent, I must point out that this dichotomy is precisely why I've always been skeptical about our collective ability to meaningfully manage binary artifacts. With binaries branding considerations become super important and I haven't seen much success around OSS foundations with striking that perfect balance between not diluting the brand AND considering the needs of downstream packagers. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
