Re: public domain no modification
Steve Langasek <firstname.lastname@example.org> wrote:
> On Tue, Apr 10, 2012 at 12:01:45AM +0200, Francesco Poli wrote:
>> > On Sat, Apr 07, 2012 at 05:05:27PM +0200, Mathieu Malaterre wrote:
>> > > Clearly §2 is meant to distinguish derived work from original work.
>> > > However in our case, this means this package will have to have its
>> > > name change whenever we need to patch the source code (eg. fix a
>> > > compilation error).
>> > This appears to be entirely consistent with the requirements of DFSG #4.
>> That's not my understanding of the issue under consideration: more
>> details are included in my own analysis .
> Yes, because as usual your analysis is way out in left field.
Lets try to keep to the facts.
>> My impression is that clause 2 introduces odd restrictions on how
>> modified versions are packaged
> "package" is synonymous with "name" in this case. DFSG#4 says free works
> may require a name change when modified.
In this case, it affects the API. It forbids creating a drop-in
replacement. I remember a large discussion on this topic when
discussing the Latex Project Public License. My recollection was that
the consensus was that drop-in replacements must be allowed.
In any case, the modified files must be put into Java files. What if
the modification is to port it to C/Python/C#/C++/Ruby/Lisp? This alone
should disqualify it from main.
>> and insists that modifications be documented in comments (which, depending
>> on how it is interpreted, may be a very strong restriction).
> You mean like this restriction?
> a) You must cause the modified files to carry prominent notices
> stating that you changed the files and the date of any change.
> You know, the one in the GPLv2?
> Your claims that this may be non-free are absurd.
Not all file types have comments. The GPL is more flexible. For
example, you can modify an image and put the required notices in the