Chiradeep, sorry, just to address your comment directly. What you suggest is untrue. If we're talking about an key/value file, then yes, there is very little expression in that. But not all config files are key/value based. Some are pure code. I've seen config files in Lua, Python, and Lisp before. POSIX sh is another common configuration format. Those things can get complex! And then you have config files that can be a bit of both. Like cron, or anything else that lets you call out to a shell.
On Thu, Sep 13, 2012 at 6:49 PM, Chiradeep Vittal < chiradeep.vit...@citrix.com> wrote: > > > On 9/13/12 7:26 AM, "David Nalley" <da...@gnsa.us> wrote: > > >> I see that Lawrence was suggesting a hypothetical that configuration > >>files > >> might not be copywritable. But I do not believe there is any precedent > >>for > >> that interpretation, and I would be nervous about jumping to > >>conclusions. > > > >Both Lawrence Rosen[1] and Richard Fontana[2] (the only IP lawyers to > >have weighed in on the subject on legal-discuss) both seem to be > >saying that generally configuration files are not copyrightable. I > >realize that isn't a bright line ruling, and that they aren't > >providing legal advice to us or the ASF, and even if they were that > >their comments aren't binding, but it's an interesting place to start. > > > > > >> 1. Identify any config files that are not derivative works (we wrote > >>them > >> from scratch) and mark these are okay. (And under the AL.) > > > >I have no idea how we would determine this. It appears that this was > >originally imported over two years ago, and was a mass import (meaning > >we lost history of anything prior to that git commit. Unless the > >person still happens to be around and recalls how they generated each > >one of the 20+ config files somewhere between 2 and 4 years ago. Then > >we have the issue of how it has been modified since then to deal with > >as well (did the person copypasta updated config from somewhere) > > > > > >> > >> 2. Identify config files that were derivative works of other files and > >>then: > >> > >> 2.1. If the original file was under 15 lines, or if the configuration > >>file > >> was obviously very simplistic such as being a simple list of key value > >> assignments, mark the file as okay. (And under the AL.) > > > >key value assignments is probably easy to determine, and I'd guess > >most would fall into this category. > > > > > >> > >> 2.2. If the original file was over 15 lines, or if the configuration > >>file > >> was complex, then: > >> > >> 2.2.1. If the original programme was AL-compatible, note the file's > >> copyright notice in LICENSE. > >> > >> 2.2.2. If the original programme was not AL-compatible, either: > >> > >> 2.2.2.1. Reach out to the original author and ask permission to use it > >>in > >> an AL licensed project. > >> > >> 2.2.2.2. Cleanroom our own configuration file. > >> > >> What do you think? Something like this? > > > > > >I'd hate to propose something that causes more work than what is > >needed, especially since the legal minds discussing it seem to suggest > >that it's a non-issue from a copyright perspective. I am also happy to > >just wait on folks at lega-discuss@ suggest. > > > >--David > > Given that there is only 1 way to write a configuration file, even if you > wrote it from scratch, it would look identical, except perhaps for > re-ordering. IANAL, the work in my opinion is not creative, but factual. > > -- NS
