Skip to main content

Derived Works: how much change info should the license require?

12 replies [Last post]
leouser
Offline
Joined: 2005-12-12

Im not an expert on licensing but it seems different licenses require amounts of notification to the user when the software is modified.

For example, copying a setion from the GPL:
http://www.opensource.org/licenses/gpl-license.php
'a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.'

this seems to say to me that you should embed in the files something like:
LOOK AT THIS!!!!: FILE CHANGE on 10/24/2021

while the Python Software Foundation License states this:
http://www.opensource.org/licenses/PythonSoftFoundation.php
'3. In the event Licensee prepares a derivative work that is based on or incorporates Python 2.1.1 or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to Python 2.1.1.'

Which to me seems to require a notification like:
1. Changed ints so they will now be doubles.
2. Changed synchronized keyword to lockthis
3. Added bytecode called invokedynamite
4. etc...

I could be reading these licenses wrong but they do seem to be different points on the spectrum of what should be required.

For myself I think Id like a detailed requirement of what has changed. If I download someones altered JVM Id like an opportunity to take in all that is different before sending it on its merry way on the command line.

So what about it, which would you feel more comfortable with?
leouser

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
robilad
Offline
Joined: 2004-05-05

@leouser: The GPL does not require listing the reason for change, but that's simply good engineering practice.

@jwenting: Indeed, some projects simply generate the changelogs with cvs2cl or similar tools, rather than maintaining them manually.

leouser
Offline
Joined: 2005-12-12

I don't know, "good engineering practice" is a good thing but if the license doesn't require it your still left to the individuals decision on how to document the thing. Its even possible that they won't even have a CVS system for you to query. Could even be just a file posted somewhere in which you download.

I think the GPL verion I quoted seems weak in this aspect and I don't think the GPL is unique in this, from peeking at a couple of other licenses they too seemed to be as primitive. The Python license seems better. Id almost prefer that the deriver have to use "good engineering practice" as a requirement to make something out of Java. Probably a mixture of both the GPL and what the Python liscense is requiring.

Ideally the license would require:
1. Files changed, date changed and what was changed.
2. Summary of what was changed but with references to #1 for further detail.

leouser

robilad
Offline
Joined: 2004-05-05

A change log written by someone who doesn't know what they are doing is going to be next to useless, no matter what level of detail the letter of the license mandates.

Is adhering to good software engineering practices desirable? Sure.

Is it desireable to have it enforced by courts? Not so much.

;)

leouser
Offline
Joined: 2005-12-12

why wouldn't it be desirable? If licenses already are requiring you to do something in the form of documentation why not require you to do it right? It seems that for the GPL someone could take me to court if I didn't have a file that listed files changed and what date it was changed on. That seems sillier to me that being taken to court because I didn't clearly explain what I had changed.

As a form of communication just requiring you to just mention what files you changed and what date they were change is weak. The python license is a better step but your still left wondering where the things happened.

Mixing the points 1 and 2 I mentioned above doesn't seem that onerous of a requirement to me.

leouser

robilad
Offline
Joined: 2004-05-05

@leouser: If you think that GPLv2's requirements in this respect are too loose, then the FSF would very much appreciate your comments on the GPLv3 draft at http://gplv3.fsf.org/ .

I don't know if this particular issue has been given much thought so far, so you could propose a better wording.

I don't think it's a particularly onerous requirement, as everyone is (or should be ;) doing it anyway.

leouser
Offline
Joined: 2005-12-12

well, Im not ragging particularly on the GPL though it is the example under discusion. I should make a list of the other liscenses that say the same thing, maybe they are GPL inspired for all I know. The PSF seems to be on a different track which is more appealing to me.

As an issue, apparently the liscense writers think that having a documentation requirement is important enough to be included as part of the liscense. From my viewpoint if the license is going to go that far and put the issue within the courts range, it may as well be for actually violating something useful.

leouser

atripp
Offline
Joined: 2003-07-15

There's no way a license is going to force people to put meaningful "change comments" in the code. Even the existing GPL requirement is pretty silly, arbitrary, and useless. So it requires me to say "I changed this file on 1/1/2006". That does no one any good. Just another GPL attempt to give the "user" some "freedom", at the expense of the original developer. I wouldn't worry about it.

leouser
Offline
Joined: 2005-12-12

true, but you could say that about anything. Just because someone may break the law doesn't mean that the law shouldn't exist.

leouser

robilad
Offline
Joined: 2004-05-05

The requirement in the GPL is satified with a change log file, usually prominently called ChangeLog, which lists the dates and files modified, and the reason for the modification.

There is no requirement to actually clutter source code files with ->>> LOOK MA! I CHANGED THE FILE! <<<<- sort of comments. ;)

What I do in practice is to have a ChangeLog.kaffe file for GPLd sources coming from other upstreams (in my case fastjar in Kaffe), which lists what has changed, and why. That way I can resync my own changes with a new upstream release without having to regenerate the change logs for the merged in version.

And users have an easier time scanning my changes, of course.

leouser
Offline
Joined: 2005-12-12

heh, I kinda of like the LOOK MA! I CHANGED THE FILE! idea. Im sure lots of folks would love writing that for each change. :D

leouser

leouser
Offline
Joined: 2005-12-12

now that Im reading robilads comments again, would the GPL satisfied with just a ChangeLog with the dates and names of the files changed or does it also need the reason it changed?

leouser

jwenting
Offline
Joined: 2003-12-02

merely pointing people to the cvs repository would be enough...
After all, it contains the complete history of the files and would at the same time fulfill the obligation to make everything available free of charge for forking.