Does LPPL allow package development with pull requests etc.?
Many packages are nowadays developed on github or similar platforms and if I want to contribute a bugfix to some package (of which I'm not the author), my usual workflow is to fork the repo, develop the bugfix, make a pull request and then I have to wait until the package author accepts my fix.
I'm wondering if my workflow is in conflict with the LPPL (LaTeX Project Public License), because in the time between developing the fix until the author accepts my pull request, the code is changed without changing the filename.
Is there some other strategy I could use, which would respect LPPL?
package-writing licensing
edited Dec 3 '18 at 18:21
someonr
6,0972759
asked Dec 3 '18 at 15:28
user176037user176037
1009
add a comment |
Many packages are nowadays developed on github or similar platforms and if I want to contribute a bugfix to some package (of which I'm not the author), my usual workflow is to fork the repo, develop the bugfix, make a pull request and then I have to wait until the package author accepts my fix.
I'm wondering if my workflow is in conflict with the LPPL (LaTeX Project Public License), because in the time between developing the fix until the author accepts my pull request, the code is changed without changing the filename.
Is there some other strategy I could use, which would respect LPPL?
package-writing licensing
edited Dec 3 '18 at 18:21
someonr
6,0972759
asked Dec 3 '18 at 15:28
user176037user176037
1009
add a comment |
Many packages are nowadays developed on github or similar platforms and if I want to contribute a bugfix to some package (of which I'm not the author), my usual workflow is to fork the repo, develop the bugfix, make a pull request and then I have to wait until the package author accepts my fix.
I'm wondering if my workflow is in conflict with the LPPL (LaTeX Project Public License), because in the time between developing the fix until the author accepts my pull request, the code is changed without changing the filename.
Is there some other strategy I could use, which would respect LPPL?
package-writing licensing
edited Dec 3 '18 at 18:21
someonr
6,0972759
asked Dec 3 '18 at 15:28
user176037user176037
1009
Many packages are nowadays developed on github or similar platforms and if I want to contribute a bugfix to some package (of which I'm not the author), my usual workflow is to fork the repo, develop the bugfix, make a pull request and then I have to wait until the package author accepts my fix.
I'm wondering if my workflow is in conflict with the LPPL (LaTeX Project Public License), because in the time between developing the fix until the author accepts my pull request, the code is changed without changing the filename.
Is there some other strategy I could use, which would respect LPPL?
package-writing licensing
package-writing licensing
edited Dec 3 '18 at 18:21
someonr
6,0972759
asked Dec 3 '18 at 15:28
user176037user176037
1009
edited Dec 3 '18 at 18:21
someonr
6,0972759
asked Dec 3 '18 at 15:28
user176037user176037
1009
edited Dec 3 '18 at 18:21
someonr
6,0972759
edited Dec 3 '18 at 18:21
someonr
6,0972759
edited Dec 3 '18 at 18:21
someonr
6,0972759
6,0972759
asked Dec 3 '18 at 15:28
user176037user176037
1009
asked Dec 3 '18 at 15:28
user176037user176037
1009
asked Dec 3 '18 at 15:28
user176037user176037
1009
1009
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The requirement to change the file name was altered several years ago; what is needed now is a prominent notice on any distribution. Code contained in a version control system has the notice in that system itself, and thus does not need to be modified to indicate a change. That applies equally to for example a Subversion client-server arrangement as to a Git distributed set up, which includes GitHub.
The point at which a 'notice' is required is when something leaves version control, for example to go to CTAN or on a webpage as a direct upload.
edited Dec 3 '18 at 22:13
user545424
372410
answered Dec 3 '18 at 15:50
Joseph Wright♦Joseph Wright
203k21557883
I am relieved! Thanks for the explanation!
– user176037
Dec 3 '18 at 16:02
I can see and would have argued myself that Sections 6(b) ["details of changes"] and 6(d) ["unmodified version"] are sort of covered by version control systems. But 6(a) seems a bit more tricky, since as I understand it would involve a change of theProvidesPackageline so that TeX "knows" the file is different when it reads it...
– moewe
Dec 3 '18 at 16:03
2
@moewe One would need real legal opinion to be sure, but I'd hope the fact that Frank etc. are happy should reassure everyone. After all, they wrote the text in the first place ...
– Joseph Wright♦
Dec 3 '18 at 16:55
@moewe I think unless there is a real reason, no-one fancies having a new version of the license ... (I intensely dislike 'author-maintained', but it's there.)
– Joseph Wright♦
Dec 3 '18 at 17:09
I can imagine that only very few people (or even no one) would be excited about a new version of the license. And I can imagine that people who are very protective about their packages might not even want to have an exception for version control systems (and would probably also not like to see 'author-maintained' go). But I'm not sure that the everyday practice and statements of intent of the LaTeX team towards the license will help me in court should it come to that, but I'm hopeful that it won't come to that.
– moewe
Dec 4 '18 at 10:23
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f462993%2fdoes-lppl-allow-package-development-with-pull-requests-etc%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The requirement to change the file name was altered several years ago; what is needed now is a prominent notice on any distribution. Code contained in a version control system has the notice in that system itself, and thus does not need to be modified to indicate a change. That applies equally to for example a Subversion client-server arrangement as to a Git distributed set up, which includes GitHub.
The point at which a 'notice' is required is when something leaves version control, for example to go to CTAN or on a webpage as a direct upload.
edited Dec 3 '18 at 22:13
user545424
372410
answered Dec 3 '18 at 15:50
Joseph Wright♦Joseph Wright
203k21557883
I am relieved! Thanks for the explanation!
– user176037
Dec 3 '18 at 16:02
I can see and would have argued myself that Sections 6(b) ["details of changes"] and 6(d) ["unmodified version"] are sort of covered by version control systems. But 6(a) seems a bit more tricky, since as I understand it would involve a change of theProvidesPackageline so that TeX "knows" the file is different when it reads it...
– moewe
Dec 3 '18 at 16:03
2
@moewe One would need real legal opinion to be sure, but I'd hope the fact that Frank etc. are happy should reassure everyone. After all, they wrote the text in the first place ...
– Joseph Wright♦
Dec 3 '18 at 16:55
@moewe I think unless there is a real reason, no-one fancies having a new version of the license ... (I intensely dislike 'author-maintained', but it's there.)
– Joseph Wright♦
Dec 3 '18 at 17:09
I can imagine that only very few people (or even no one) would be excited about a new version of the license. And I can imagine that people who are very protective about their packages might not even want to have an exception for version control systems (and would probably also not like to see 'author-maintained' go). But I'm not sure that the everyday practice and statements of intent of the LaTeX team towards the license will help me in court should it come to that, but I'm hopeful that it won't come to that.
– moewe
Dec 4 '18 at 10:23
add a comment |
The requirement to change the file name was altered several years ago; what is needed now is a prominent notice on any distribution. Code contained in a version control system has the notice in that system itself, and thus does not need to be modified to indicate a change. That applies equally to for example a Subversion client-server arrangement as to a Git distributed set up, which includes GitHub.
The point at which a 'notice' is required is when something leaves version control, for example to go to CTAN or on a webpage as a direct upload.
edited Dec 3 '18 at 22:13
user545424
372410
answered Dec 3 '18 at 15:50
Joseph Wright♦Joseph Wright
203k21557883
I am relieved! Thanks for the explanation!
– user176037
Dec 3 '18 at 16:02
I can see and would have argued myself that Sections 6(b) ["details of changes"] and 6(d) ["unmodified version"] are sort of covered by version control systems. But 6(a) seems a bit more tricky, since as I understand it would involve a change of theProvidesPackageline so that TeX "knows" the file is different when it reads it...
– moewe
Dec 3 '18 at 16:03
2
@moewe One would need real legal opinion to be sure, but I'd hope the fact that Frank etc. are happy should reassure everyone. After all, they wrote the text in the first place ...
– Joseph Wright♦
Dec 3 '18 at 16:55
@moewe I think unless there is a real reason, no-one fancies having a new version of the license ... (I intensely dislike 'author-maintained', but it's there.)
– Joseph Wright♦
Dec 3 '18 at 17:09
I can imagine that only very few people (or even no one) would be excited about a new version of the license. And I can imagine that people who are very protective about their packages might not even want to have an exception for version control systems (and would probably also not like to see 'author-maintained' go). But I'm not sure that the everyday practice and statements of intent of the LaTeX team towards the license will help me in court should it come to that, but I'm hopeful that it won't come to that.
– moewe
Dec 4 '18 at 10:23
add a comment |
The requirement to change the file name was altered several years ago; what is needed now is a prominent notice on any distribution. Code contained in a version control system has the notice in that system itself, and thus does not need to be modified to indicate a change. That applies equally to for example a Subversion client-server arrangement as to a Git distributed set up, which includes GitHub.
The point at which a 'notice' is required is when something leaves version control, for example to go to CTAN or on a webpage as a direct upload.
edited Dec 3 '18 at 22:13
user545424
372410
answered Dec 3 '18 at 15:50
Joseph Wright♦Joseph Wright
203k21557883
The requirement to change the file name was altered several years ago; what is needed now is a prominent notice on any distribution. Code contained in a version control system has the notice in that system itself, and thus does not need to be modified to indicate a change. That applies equally to for example a Subversion client-server arrangement as to a Git distributed set up, which includes GitHub.
The point at which a 'notice' is required is when something leaves version control, for example to go to CTAN or on a webpage as a direct upload.
edited Dec 3 '18 at 22:13
user545424
372410
answered Dec 3 '18 at 15:50
Joseph Wright♦Joseph Wright
203k21557883
edited Dec 3 '18 at 22:13
user545424
372410
edited Dec 3 '18 at 22:13
user545424
372410
edited Dec 3 '18 at 22:13
user545424
372410
372410
answered Dec 3 '18 at 15:50
Joseph Wright♦Joseph Wright
203k21557883
answered Dec 3 '18 at 15:50
Joseph Wright♦Joseph Wright
203k21557883
answered Dec 3 '18 at 15:50
Joseph Wright♦Joseph Wright
203k21557883
203k21557883
I am relieved! Thanks for the explanation!
– user176037
Dec 3 '18 at 16:02
I can see and would have argued myself that Sections 6(b) ["details of changes"] and 6(d) ["unmodified version"] are sort of covered by version control systems. But 6(a) seems a bit more tricky, since as I understand it would involve a change of theProvidesPackageline so that TeX "knows" the file is different when it reads it...
– moewe
Dec 3 '18 at 16:03
2
@moewe One would need real legal opinion to be sure, but I'd hope the fact that Frank etc. are happy should reassure everyone. After all, they wrote the text in the first place ...
– Joseph Wright♦
Dec 3 '18 at 16:55
@moewe I think unless there is a real reason, no-one fancies having a new version of the license ... (I intensely dislike 'author-maintained', but it's there.)
– Joseph Wright♦
Dec 3 '18 at 17:09
I can imagine that only very few people (or even no one) would be excited about a new version of the license. And I can imagine that people who are very protective about their packages might not even want to have an exception for version control systems (and would probably also not like to see 'author-maintained' go). But I'm not sure that the everyday practice and statements of intent of the LaTeX team towards the license will help me in court should it come to that, but I'm hopeful that it won't come to that.
– moewe
Dec 4 '18 at 10:23
add a comment |
I am relieved! Thanks for the explanation!
– user176037
Dec 3 '18 at 16:02
I can see and would have argued myself that Sections 6(b) ["details of changes"] and 6(d) ["unmodified version"] are sort of covered by version control systems. But 6(a) seems a bit more tricky, since as I understand it would involve a change of theProvidesPackageline so that TeX "knows" the file is different when it reads it...
– moewe
Dec 3 '18 at 16:03
2
@moewe One would need real legal opinion to be sure, but I'd hope the fact that Frank etc. are happy should reassure everyone. After all, they wrote the text in the first place ...
– Joseph Wright♦
Dec 3 '18 at 16:55
@moewe I think unless there is a real reason, no-one fancies having a new version of the license ... (I intensely dislike 'author-maintained', but it's there.)
– Joseph Wright♦
Dec 3 '18 at 17:09
I can imagine that only very few people (or even no one) would be excited about a new version of the license. And I can imagine that people who are very protective about their packages might not even want to have an exception for version control systems (and would probably also not like to see 'author-maintained' go). But I'm not sure that the everyday practice and statements of intent of the LaTeX team towards the license will help me in court should it come to that, but I'm hopeful that it won't come to that.
– moewe
Dec 4 '18 at 10:23
I am relieved! Thanks for the explanation!
– user176037
Dec 3 '18 at 16:02
I am relieved! Thanks for the explanation!
– user176037
Dec 3 '18 at 16:02
I can see and would have argued myself that Sections 6(b) ["details of changes"] and 6(d) ["unmodified version"] are sort of covered by version control systems. But 6(a) seems a bit more tricky, since as I understand it would involve a change of the
ProvidesPackage line so that TeX "knows" the file is different when it reads it...– moewe
Dec 3 '18 at 16:03
I can see and would have argued myself that Sections 6(b) ["details of changes"] and 6(d) ["unmodified version"] are sort of covered by version control systems. But 6(a) seems a bit more tricky, since as I understand it would involve a change of the
ProvidesPackage line so that TeX "knows" the file is different when it reads it...– moewe
Dec 3 '18 at 16:03
2
2
@moewe One would need real legal opinion to be sure, but I'd hope the fact that Frank etc. are happy should reassure everyone. After all, they wrote the text in the first place ...
– Joseph Wright♦
Dec 3 '18 at 16:55
@moewe One would need real legal opinion to be sure, but I'd hope the fact that Frank etc. are happy should reassure everyone. After all, they wrote the text in the first place ...
– Joseph Wright♦
Dec 3 '18 at 16:55
@moewe I think unless there is a real reason, no-one fancies having a new version of the license ... (I intensely dislike 'author-maintained', but it's there.)
– Joseph Wright♦
Dec 3 '18 at 17:09
@moewe I think unless there is a real reason, no-one fancies having a new version of the license ... (I intensely dislike 'author-maintained', but it's there.)
– Joseph Wright♦
Dec 3 '18 at 17:09
I can imagine that only very few people (or even no one) would be excited about a new version of the license. And I can imagine that people who are very protective about their packages might not even want to have an exception for version control systems (and would probably also not like to see 'author-maintained' go). But I'm not sure that the everyday practice and statements of intent of the LaTeX team towards the license will help me in court should it come to that, but I'm hopeful that it won't come to that.
– moewe
Dec 4 '18 at 10:23
I can imagine that only very few people (or even no one) would be excited about a new version of the license. And I can imagine that people who are very protective about their packages might not even want to have an exception for version control systems (and would probably also not like to see 'author-maintained' go). But I'm not sure that the everyday practice and statements of intent of the LaTeX team towards the license will help me in court should it come to that, but I'm hopeful that it won't come to that.
– moewe
Dec 4 '18 at 10:23
add a comment |
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f462993%2fdoes-lppl-allow-package-development-with-pull-requests-etc%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
