incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [ASFCS40][DISCUSS] How should we move forward to resolution on the config files in "patches"? Was: "Re: [ASFCS40] Configuration file licensing followup"
Date Thu, 13 Sep 2012 18:36:10 GMT
Saying that configuration files, in all cases, are not copywritable because
that are, on the whole, not as complex as code is like saying that blog
posts, in all cases, are not copywritable because they are, on the whole,
not as complex as books.

The law is much more nuanced than that. There is no way we can say, up
front, whether a configuration file is protected by copywrite or not. The
unwillingness to commit to anything on legal-discuss is an indication of
this. (It was made explicit that with a vague question, there will only be
vague answers.)

It might be better to actually document what we have, and then present that
to legal discuss and take it from there.

Let's get concrete.

We should put together a list of each config file path, along with
information such as:

* Size of file
* Complexity (key/value, code snippets, what?)
* Copyright notice or license header?
* License of project it (may) have been taken from
* Origin (Citrix, upstream project, unknown?)

Once we have a complete picture, I think we can talk about how to proceed.

(And hopefully propose a guideline for future config files.)

I certainly do not think we are in a position to write of an entire
category of data as being uncopywritable.

I am happy to run this to pursue this with legal too, but I think we need a
better view of what we're dealing with.


On Thursday, September 13, 2012, David Nalley 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:
> >
> > Reach out to the original author and ask permission to use it in
> > an AL licensed project.
> >
> > 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message