Le jeudi 31 janvier 2013 15:43:45, Mateusz Kijowski a écrit : > What would be the proper approach to this? The easiest way would be to > package pgbadger with the inline modified module, but I doubt that it > is the proper way. It's not the best way. But the inline version of SQL::Beautify is indeed embedded in pgbadger so there's no risk of clash between pgbadger file and original SQL::Beautify module. > Another approach would be to prod the SQL::Beautify > module developer to consider the changes made by pgbadger developer, > and then package the patched module as a separate perl package. To answer, we need to know the amount of modification between original SQL::Beautify and its inlined version and its impact on backward compatibility. > Another issue is that the script itself has BSD license, but the > module has Artistic License 2.0. Both of them are in one file, so I am > wondering if debian/copyright permits a file to have two different > licenses for two parts of a file. I don't think that a problem. Copying code within a file is another form of aggregation of work. Since the licenses are compatible, it's not a big deal. The pgbadger entry in the copyright will have to list all copyright owners (with the inlined javascript author) and list the licenses (e.g. "License: BSD and Artistic and ...) . A comment to explain the concatenation of work in a single file would not hurt. All in all, I don't think there a roadblock to package pgbadger as is even if the resulting package will be lackluster. Thoughts ? Dominique
Attachment:
signature.asc
Description: This is a digitally signed message part.