On 16 July 2013 18:34, Emmanuel Lécharny <elecha...@gmail.com> wrote: > Le 7/16/13 6:48 PM, sebb a écrit : >> >>>>>> 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. > > Being a english native speaker, you may find it pretty well written. I'm > not, and I find that some of the sentences quite convoluted. > > I have already stated that instead of producing a bunch of verbose > explainations and nothing else, the addition of samples could help. > > It's pretty much like if you were to read the API specification with no > sample at all... > > >> >>> 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. > > It loooks like so to me. It's just a feeling, but it's shared by many > people. > > > >> >>> 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. > > Now you are specifically describing what is a dependency. But this is > not even close to what a dependency is : is an image a dependency, > assuming the code does not depend on it ? > > What I want to stress out is that the terms are vague, and swamped into > a long list of sentences that does not help to clarify the intention of > those who wrote those pages (not to mention the misleading links to > other pages) > >> In a Maven context it will be a jar, in a C-project it might be a DLL, etc. > > That's better. Having such a sentence in this page would have helped. > > I have read the page many times in the past years, and I have been > released at least 3 different projects (MINA, ApacheDS and Ldap API) for > many years. I have trie dmy best to understand what were the > requirement, and so far, I must say that I have miserabily failed. > > Blame me, but then I'm not the only one to blame. Julien has also spent > many times trying to get the N&L files correct, and it seems he is as > lame as I am. I know other people from other projects having the exact > same problem (I have mentored the Shiro and Syncope projects, and they > faced the same problem too : they are probably retarded...) > > *or* the existing documention is simply sub-optimal... > >> >>> 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? > > true. Here, I'm just rambling, I know. May be when I will be done with > my three current projects' bugs, after I have moved from my old house to > the new one, once I have managed the trial I'm engaged in with my > father's associate, and various other hazards I have to deal with this > month and the next one, then yes, I will push a mail to legal. > >> >>>> 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. > > I know that I embed slf4j. I know that slf4j embeds at least 3 other > jars itself. This is all I know... > > I'm expecting Slf4j to fulfill their duty regarding the inclusion of the > needed NOTICE and LICENSE, and that it reflects in their own LICENCE and > NOTICE file. > >> >> 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 has nothing to do with transitive dependencies. > > >> >>> 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? > Searching for every transitive dependencies for dependencies we include > into our packages. > >> >> 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. > Sorry, but I don't see what's your point is here... Why should I build a > bundle for a dependency I'm downloading from maven ? >
I don't know how many different ways I can say this: The N&L files need to agree with whatever the PMC releases or distributes - i.e. the source and binary archives, and the Maven jars. The SCM (SVN/Git) counts as a distribution since it is generally published to all (it's not reserved to developers) so it's important that users see the N&L files at the published URL(s) So the N&L files in SVN/Git must relate to the files in the SCM tree; almost always the source bundle is created from SCM so the same N&L files will be suitable for the source bundle as well. The binary bundle normally consists of the compiled source, maybe plus Javadoc, maybe with some example sources. All that is derived from the SCM source so the same N&L applies. However, some projects include other items that are needed at run-time - e.g. jars or DLLs. The N&L must be updated to take account of any of these items that are actually included in the binary archive. If they are other Apache products, probably nothing needs to be added to N&L If they are external products - e.g. JUnit - then their LICENSE must be included and if necessary the NOTICE must be updated. Is that clear now? > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
