DFSG-alikes for non-software? [was Re: DFSG and fonts [was: Bug#91856: Hello]]

[idalton@ferret.phonewave.net]

On Wed, Apr 04, 2001 at 09:05:31PM -0700, idalton@ferret.phonewave.net wrote:
> On Wed, Apr 04, 2001 at 07:50:06PM +0100, Edmund GRIMLEY EVANS wrote:
> > Joseph Carter <knghtbrd@debian.org>:
[Reducto ad absurdum: GPL as example to show that maybe it isn't
reasonable to apply the DFSG to all kinds of data]


Thank you for asking, Edmund. Hopefully some discussion will happen and
more people will become epistemicly aware.


I've come up with five types of content data for which I believe
seperate classes of licensing make sense.

0) General-purpose executable code.
1) Non-GP code such as downloadable firmware/BIOS images.
2) Code metadata such as documentation, copyright, and license.
3) Human-parseable data such as images (inc. fonts) and sounds.
4) Human-language text (dictionary, fiction, etc) not covered by 2.


Item 0 of course is represented by the DFSG. I believe the DFSG is
inappropriate for all other items in at least one way. This post
attempts to explain what my views are and invite discussion.


The Debian Free Software Guidelines

  1. Free Redistribution
No issues
  2. Source Code
  3. Derived Works
  4. Integrity of The Author's Source Code
  5. No Discrimination Against Persons or Groups
No issues
  6. No Discrimination Against Fields of Endeavor
No issues
  7. Distribution of License
No issues
  8. License Must Not Be Specific to Debian
No issues
  9. License Must Not Contaminate Other Software
No issues
 10. Example Licenses
(?)

So the only sections I see that are not wholly appropriate for 
non-(GP code) are #2 and #(3,4) which go together.


Class 1: 

* (derived works) I feel it may be so much more important to KNOW that
  the work has been modified by a third party, that these modifications
  be marked so, and accompanied by the unmodified version.

* (source code) As firmware is meant to be loaded on a special-purpose
  peripheral device FOR the correct functioning of said device (such as
  a SCSI host adapter) and in general will not work on any different
  device (even a different model of host adapter in extreme case),
  source code is not important in the same way (the firmware binary may
  even BE the source code) and should not be required.

* (note DFSG 6) Use of firmware on a 'device' emulated in GP code, even
  for the purpose of attempting to reverse-engineer the device or the
  firmware, cannot be forbidden by the firmware license. On the other
  hand, this may be forbidden by other law outside the scope of the
  license.

Class 2:

* (source code) Either plain text or SGML marked-up probably should be
  the prefered form.

* (derived works) Presentation translation (such as printing the
  document, formatting it in an alternate documentation format, speaking
  it aloud, etc, should be allowed. Documentation of course should be
  able to be edited for technical accuracy against the code/process
  documented, and be translated. However..

* (derived works: copyright notice and license) These should allow
  'unofficial' translations when distributed along with verbatim copies
  of the original. Derived works MUST be differentiated from the
  original (as in DFSG 4) so it is clear the work(s) the original
  license/copyright applies to is not intended to be covered by the
  derived license/copyright. Copyright may be appended (prepended) when
  creating a derived work from the covered work.

* (I've probably mangled this part, but it should get the idea across)

Class 3:

* (source code) I'm not sure how this can consistantly apply. I mean
  (being somewhat facetious here) If I distribute an audio file of my
  saying the word 'fnord' does source code mean I have to include a
  duplicate of my body from the torso up? ;)

* (derived works) Changes in presentation should always be
  allowed. Changes in content, even with a requirement that they be
  marked as 'unofficial' in some way, should be strongly encouraged but
  (possibly) not necessarily required.

Class 4:

* (source code) Probably doesn't even apply. But if it does, plain text
  or SGML marked-up should be the prefered form.

* (derived works) Assuming everything else is met (redistribution, etc)
  and the license allows for changes in presentation, changes in content
  do not have to be allowed, but we should still encourage it.