[EMAIL PROTECTED] said: > On Wed, Apr 04, 2001 at 09:05:31PM -0700, [EMAIL PROTECTED] wrote: > > On Wed, Apr 04, 2001 at 07:50:06PM +0100, Edmund GRIMLEY EVANS wrote: > > > Joseph Carter <[EMAIL PROTECTED]>: > [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.
Define the differences. Example, why is documentation the same as license (and I see those as two different things, due to the legalities involved in licenses)? What is the difference between GP code and non-GP code? > > > 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. As important as it may be to know that something is derived, it is also important to know what changed, and what it does. > > * (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. Maybe we want the source code to fix glitches in the SW? Also, it could help us write the code for another, similar device. > > * (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. Try the FSF Free Documentation License (http://www.fsf.org/copyleft/fdl.htm l) - it addresses most of the issues with documentation. > > * (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? ;) In this case (an mpeg or .ogg file), it is the source code, similar to documentation. Of course, I can run it through various SW to modify it (extend the length, change pitch, etc), would be OK under DFSG, but you could require that the new file have a new name / attribution, etc. > > * (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. But if I want to extend / fix it, if I'm not allowed to make mods & redistribute, how do I do it? Maybe I want to add something to a font (don't ask why, the why is not important, the action is)? > > 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. If I can't change the content, I can't fix / extend it. I understand artist integrity. That's fine (he who creates the work chooses the license). However, there's nothing that says we have to accept the license. jeff ------------------------------------------------------------------------ Jeffry Smith Technical Sales Consultant Mission Critical Linux [EMAIL PROTECTED] phone:603.930.9739 fax:978.446.9470 ------------------------------------------------------------------------
