Re: public domain no modification
Steve Langasek <vorlon@debian.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 [1].
>
> 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
image itself.
Cheers,
Walter Landry
wlandry@caltech.edu
Reply to: