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 ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
