Re: New OPL Draft
Branden Robinson wrote:
> Flowery language about artistic expression and brush strokes upon the
> canvas is well and good, but these concepts are subjectively evaluated. I
That was for ldp-discuss.
Documentation licensing issues have been topics of hot debate on the LDP
mailing list for years, and I'm frustrated by a growing trend toward,
with no lofical explanation of, documentation having different licensing
than the software it documents. Even the FSF are doing it. Most
explanation boils down to wanting to allow documentation authors a
declared right of "artistic expression" while denying software
developers the same right.
> Any DFCL enterprise is necessarily going to have to restrict itself from
> making assertions about "artistic" versus "technical" intent, just as the
> existing DFSG does.
> What I propose boils down to this:
>
> Is it a candidate for main/contrib/non-free? If so, apply the DFSG.
>
> Is it a candidate for data? If so, apply the DFCG.
My question for this list is: Why should "content" have a different set
of licensing guidelines?
> Our archive layout will not allow a package to into both, say, main and
> data, so your aggravted relatvistic concerns about "what's non-executable
> data and what isn't" have already been addressed by an accepted amendment
> to policy. So I suggest you refocus that aspect of your grief upon milk
> that has already been spilt. You may read
> <http://www.debian.org/Bugs/db/38/38902.html> to see how the machete of
> practicality has already been taken to your garden of subjectivity.
I did, and I don't understand its relevance.
> We decide first if a package is bound for data or not, before we worry
> about its license. What I suggest is that we may permit VPL (Verbatim
Yes, I understood that.
> The important issue is: with the introduction of the data section, which
> won't contain software per se, we need a companion document to the DFSG
> that will determine what is acceptable for admission into that section and
> what is not.
I understand, and the thrust of my "please don't" was "please don't"
treat non-executable data differently to "executable" data from a
license evaluation perspective. I believe the same baseline freedoms
should apply.
> Finally, I think you need to reflect on why we consider the freedom of the
> user to modify and redistribute software our core principle. Is it so we
> can realize some collectivist utopia of artistic collaboration? No. It's
> because we want computer systems that work as we desire.
I've reflected many times on this, and take some affront at the
suggestion that I haven't.
I think this is a limited view of why freedom of modification and
redistribution is a desirable principle.
That aside, I pose the question: Is that argument not equally
appropriate to data? If I find an error in data, why should I not be
able to correct it, and share that improvement of the data with others?
If I believe that a data-set is good, but that I could add value to it
and improve it, why should I not be able to do this and share this with
others? There is certainly some data that might be considered
inappropriate to modify; data considered "perfect" or definitive for
example; but this too applies to certain software and is a subjectively
evaluated decision because it often relies on qualitative measures
rather than quantitative ones.
Terry
Reply to: