Okay, sorry about this, I followed your original links. Dozy morning. ;)

If you're writing a config file by hand, and there it is not a derivative
work, then I believe it is fine. (Even if you used a GPL manual or such.
The actual composition is a creative work on your part.)

However, just because a config file shipped with a GPLed piece of software
does not have any license headers on it DOES NOT mean that it is
not licensed. It could be covered by a broader COPYING file at the root of
the project. HOWEVER, if it did mean that it was not licensed, then
copyright protection would apply IN FULL. Because that's how copyright
works.

So if you find a configuration file without a license header, you have to
assume full copyright, not public domain.

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.

Okay, so I'm caught up now.

I'd propose that we:

1. Identify any config files that are not derivative works (we wrote them
from scratch) and mark these are okay. (And under the AL.)

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.)

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?

We could propose this to legal to see what they think.

On Wed, Sep 12, 2012 at 8:42 PM, Chip Childers <chip.child...@sungard.com>wrote:

> Hi all,
>
> (Looking for mentor guidance here as well please!)
>
> On this topic, we need to come together as a community to figure out
> how we want to proceed with these configuration files.  It doesn't
> seem like we are going to get a definitive answer on legal-discuss@a.o
> without asking about a specific file from a specific source.  There
> HAS been a little discussion about the ability of a configuration file
> to be copyright on the legal list, but it didn't go much further than
> a couple of emails.
>
> As far as I can tell, we have some options:
>
> 1 - Do a file by file audit to confirm the source and if there is any
> claim of copyright on those files, and then either:
> 1.A - Ask the source project if they would consider granting a
> different license for just that config file.
> 1.B - Ask legal-discuss@a.o for specific exemptions
> 1.C - Do nothing, because the file isn't something that a copyright is
> claimed on (and we wouldn't claim a copyright either)
> 1.D - Spec out the requirements, and have someone attempt a clean-room
> implementation (I think that I could find someone if it gets to this)
> 2 - Follow up on the concept of configuration files not being
> protected by copyright, and ask for a ruling from legal-discuss on
> that idea.
>
> There may be other options that I'm missing.  I'm looking for opinions
> and suggestions for how to move forward, since this is absolutely one
> of the blocker issues for a 4.0 release.  Thoughts?
>
> -chip
>
> On Thu, Sep 6, 2012 at 2:36 PM, Chip Childers <chip.child...@sungard.com>
> wrote:
> > Chiradeep,
> >
> > Would you mind putting together the specific example data being
> > requested by Daniel [1] on legal-discuss@a.o in response to the legal
> > Jira that you raised [2]?
> >
> > The legal thread includes some discussion on the possibility of config
> > files even being something that could enjoy license protection, but we
> > should probably plan on dealing with the potential provenance issues
> > anyway.
> >
> > -chip
> >
> > [1] - http://markmail.org/message/p6kxbvzybyu552p2
> > [2] - https://issues.apache.org/jira/browse/LEGAL-146
>



-- 
NS

Reply via email to