On 16 July 2013 14:01, Emmanuel Lécharny <elecha...@gmail.com> wrote: > Le 7/16/13 12:08 PM, sebb a écrit : >> On 16 July 2013 08:41, Emmanuel Lécharny <elecha...@gmail.com> wrote: >>> Le 7/16/13 1:14 AM, sebb a écrit : >>>> Have you seen this? >>>> >>>> http://www.apache.org/dev/licensing-howto.html#mod-notice >>>> >>>> It suggests that additions to NOTICE should be quite rare. >>> The NOTICE files just contain the Apache License reference as of today. >>> The one used for binary contains a ref rto SLF4J and Protobuf, which are >>> distributed with the bin. I think this corretly fits with the requirements. >> I'm not sure that entries in NOTICE are required. > Right... " If the dependency supplies a |NOTICE| file, its contents must > be analyzed and the relevant portions bubbled up into the top-level > |NOTICE| file." > > For protobuf, this is not needed. We just have to add the protobuf > licence into the LICENSE-bin file. > For SLF4J, this is exactly the same thing. > > I will remove anything related to those two jars from the NOTICE-bin > file (which will ^robably be removed, as it has teh same content than > NOTICE) > > >>> The very same for the LICENSE files. >> Yes, LICENSE does need entries (or pointers to other files) for all >> included bits. > > +1
OK. >> >>>> It is important that the N&L files relate to the bits which are >>>> actually included. >>>> >>>> This means that the N&L files at the top level of SVN can be used >>>> directly for the source archive, as the archive and SVN should >>>> generally agree (bar maybe the DOAP). >>>> >>>> The binary archive may need additional License (and occasionally) >>>> Notice entries, depending what is additionally bundled. >>> Yes. It has been corrected yesterday, and I just pushed the modifications. >>> >>> >>> >>> Btw, I really think that the >>> http://www.apache.org/dev/licensing-howto.html is far from being easy to >>> understand for not native english speakers, especially by those who have >>> not a degree in law school... >> What is not clear? Please raise that with Infra. > > You are wondering ??? ;-) In how many projects are you trying to get > those files corrected ? I can't imagine I'm the only one not being able > to decipher the pretty convoluted semi-legal text on this page. I find that page quite clear, apart from the link to /legal, which is very unhelpful. > Legal texts are fine assuming you don't have to read them, and as soon > as you have a lawyer reading above your shoulder and correcting you > immediately when you do something wrong (kind of what you are doing > here, and you must be blessed for taking care of those details !). We > are dumb developpers, quite good at finding bugs, coding large software, > but not very good when it comes to contracts... That page is not intended as a legal text. > What do I find "not clear" ? Unless I read every single line ten times, > I'm ot able to decide what to do or what not to do. What is a > "dependency" ? This is a contextful terfm, which meeans something in a > Maven context and something else in another context. I don't see any distinction there. A dependency is something the code depends on. In a Maven context it will be a jar, in a C-project it might be a DLL, etc. > How do we manage the jars used only during tests ? Same as for any other dependency - only the bits that are included matter. If the code requires JUnit at test time and JavaMail at runtime, the only thing that matters is whether or not the archive includes JUnit and/or JavaMail. > Another pb : there is a link on this page : > http://www.apache.org/dev/licensing-howto.html#overview-of-files which > refers to this other page : http://www.apache.org/legal/. Literarelly, > it says : > > " The complete requirements for |LICENSE| and |NOTICE| are described > elsewhere <http://www.apache.org/legal>." (elswhere --> > http://www.apache.org/legal/) Now, find where in this page you have > anything directly related to the NOTICE file... Yeah, if you dig a bit, > you find it on http://www.apache.org/legal/src-headers.html#notice... > Note that this link can be found when clicking on the " Source Header > and Copyright Notice Policy > <http://www.apache.org/legal/src-headers.html>" link. Not really user > friendly... I agree about that link. > I can go on and on, but frankly, I have no time nor energy to fight with > infra about the content of this file. I consider that it's a task that > should be fulfiled by legal@a.o, and we probably need a working group to > add some samples helping people like me to know what to do. But unless you explain what you find difficult to understand, how can anyone hope to fix it? > >> >>> There are a few use cases that would >>> benefit the whole community if they were included in this page, like : >>> - junit, what to do regarding N&L files ? >>> - slf4j/log4j, what to do regarding N&L files? >> In that case, please ask on legal discuss / infra. > That would be the Nth time I would ask them for such informations. I was > able to find a mail I sent to them last year, and I've got only one > answer from someone not part of the legal team. > > Seriously, it's years those questions are asked, and most certainly > answered, with no will to collect the valuable answer on a single page > for the common good. Not blaming them though, bt this is just a waste of > energy from both sides... > >> >>> - transitive dependencies like cal10n-api.jar (inlcuded by slf4j), what >>> to do regarding N&L files ? (note that it could be a dependency of >>> another jar than slf4j, I just picked this one because I know that slf4j >>> depends on this jar). >> Transitive dependencies are no different from other dependencies - are >> the bits actually included? > No, because I have no idea what dependency are transitively included. You may not know what the transitive dependencies are, but I would hope you know what is actually in the binary archive. Again, only the bits that are actually included in the archives matter for the purpose of the N&L files. If a file is needed at run-time or test-time - or even compile time - if it is not included in the bundle then it has no business being mentioned in the N&L files. If a file is included, it must be covered by the N&L files If it is not included, the N&L files should not mention it. > This is again an extremely time consumming task, and I can't believe > that it has not already been done on one of the 100 projects at the ASF, > and gathered in a common place... Sorry, what is time consuming? The N&L files only depend on what is in the archives. It's just a question of checking that everything that is included in the bundles is covered in the N&L files. The contents should be obvious from the assembly files; if not, just build the bundles and see what they contain. > I'm a volunteer, this is a best effort work, and if I miss something, > then I'd rather fix it once someone show me how to fix it rather than > spending hours (days ?) to dig many external jars, many incomplet or > cryptic web pages to get it right at first. And guess what ? I'm not the > only one having through those balls... Again, if web-pages seem cryptic to you, they won't fix themselves. > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
