3 ms·

The GPLv2 (BusyBox) says the end-user needs to have access to the changed sources (for example a link to it) and a copy of the license IF and just IF you redist

by nix23 4y ago

The GPLv2 (BusyBox) says the end-user needs to have access to the changed sources (for example a link to it) and a copy of the license IF and just IF you redistribute the Code. The link could be very well a magnetlink to a tar or a patch-file on pastebin (and since it's a patch you already say whats changed and when 2a from the GPLv2 resolved). You don't need to include scripts or documentation or anything relating to building or running it in production, who told you that BS?

zamadatix 4y ago
Maybe you have this confused with a different license or non commercial use? GPLv2 requires full source + patches, you can’t just link a diff and call it a day. It also has to actually be reachable for a minimum period, you can’t just throw out a magnet link and say someone else will provide it when you are asked (always seeding the magnet link is valid but not particularly easier for you). Using a 3rd party puts you in an awkward place if that 3rd party host disappears next year for some crazy reason. Build scripts such as make files are definitely required with the exception of what the license gives. As for where I’m hearing this both the busy ox license FAQ and the gnu.org GPL FAQ agree, as does the text of the license.
- nix23 4y ago
  Your making problem's up where no are, make a textfile trow in your for example *gnu.org links for the full source and trow in your patches at the end of the file. >you can’t just throw out a magnet link and say There are webseed's too with your 2kb textfile on a web-server or github, or hey just trow it on github completely, or send it to an archives maillist. I hope i never have a meeting with you, you act like it's a moon mission and not just a really simple copy-paste gist.
  - zamadatix 4y ago
    As I said > Not particularly difficult/onerous just easy to overlook or later forget And as the busybox license page says > Complying with BusyBox's license is easy. Get your act together, fight with internal inertia inside your company and it will be okay. Neither of these statements are painting it out to be a moon mission but are acknowledging compliance is frequently a problem anyways. After all if it wasn't they wouldn't need dedicated pages about companies not knowing what to do when called out as non-compliant if companies didn't have issues staying compliant despite it being easy. Also again don't forget the build/installation scripts in your "full source" (or an explicit comment that it is unmodified), this is another common source of non-compliance. Despite this also being extremely simple to do from an effort perspective you yourself were saying was unneeded BS just a few comments ago. The relevant text from the GPLv2 itself: > For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. And the busybox license page's comment on this often going awry: > Some companies get in trouble because although they use an upstream vanilla source tarball, they don't say what version it was, or they don't explicitly say it wasn't modified, and they don't include “the scripts used to control compilation and installation of the executable”. Then when we approach them for more information, they don't understand what we could possibly want, and panic. Please don't panic; just work with us.
    - nix23 4y ago
      Moon mission man again: >>3(a) bundle the complete, corresponding source with the binary. >>Using option 3(a), that is, putting exact BusyBox source and .config file you used to build the binary on the same medium which you use to ship the binary, plus "the scripts used to control compilation and installation of the executable" is the most bullet-proof approach to license compliance. If you do that, you can stop reading, your license obligations have likely been satisfied. ->is the most bullet-proof approach ->you can stop reading, your license obligations have likely been satisfied. This is the Link: https://www.busybox.net/license.html https://www.busybox.net/license.html They get angry if you don't make what the license says 1.5 year after they warned you...it's their right to do so. 60% of your comment are just mutated strings of text to fit your narrative. However, BSD/ISC/MIT are the better licenses anyway (for 99%), i don't want lawyers involved in a technical project if possible...also no Stallman's or free beer discussions.
      - zamadatix 4y ago
        This is the page I have been referring to since you wrote "As far as I know, the requirement is to dump a tarball of any changes you made on a web server". Again what's on that page and what you were saying clearly disagreed, just go back and read your original comments now that you understand the distribution requirements. Nobody has been saying the requirements are complicated just easily missed. Despite the message of "if you do that, you can stop reading" imagine you might not always be able to do that and read on through to the following regarding option 3(b) which deals with their recommendation for what to do when you ship the binaries with firmware, the most common method of distributing copies of busybox. 3(a) is the simplest way for general software but it doesn't really make sense for the firmware distribution use case, as they note. Either way both 3(a) and 3(b) are completely different from what you were originally proposing to do and they both requiring delivering full source + build/install scripts even if you don't otherwise redistribute the source (just redistributing the binary is enough). Nothing complicated as long as you can get people to read the license page first. So far everything here but your earlier comments agree many other licenses are easier to comply with and it's not worth worrying about. This is why the original comment recommended looking at Toybox, a BSD licensed alternative, for the reasons you just listed. There's not any need to constantly call names or say responses are BS, the content of each message already speaks to its own value.

by nix23 4y ago

zamadatix 4y ago

Maybe you have this confused with a different license or non commercial use? GPLv2 requires full source + patches, you can’t just link a diff and call it a day. It also has to actually be reachable for a minimum period, you can’t just throw out a magnet link and say someone else will provide it when you are asked (always seeding the magnet link is valid but not particularly easier for you). Using a 3rd party puts you in an awkward place if that 3rd party host disappears next year for some crazy reason. Build scripts such as make files are definitely required with the exception of what the license gives. As for where I’m hearing this both the busy ox license FAQ and the gnu.org GPL FAQ agree, as does the text of the license.

nix23 4y ago
Your making problem's up where no are, make a textfile trow in your for example *gnu.org links for the full source and trow in your patches at the end of the file. >you can’t just throw out a magnet link and say There are webseed's too with your 2kb textfile on a web-server or github, or hey just trow it on github completely, or send it to an archives maillist. I hope i never have a meeting with you, you act like it's a moon mission and not just a really simple copy-paste gist.
- zamadatix 4y ago
  As I said > Not particularly difficult/onerous just easy to overlook or later forget And as the busybox license page says > Complying with BusyBox's license is easy. Get your act together, fight with internal inertia inside your company and it will be okay. Neither of these statements are painting it out to be a moon mission but are acknowledging compliance is frequently a problem anyways. After all if it wasn't they wouldn't need dedicated pages about companies not knowing what to do when called out as non-compliant if companies didn't have issues staying compliant despite it being easy. Also again don't forget the build/installation scripts in your "full source" (or an explicit comment that it is unmodified), this is another common source of non-compliance. Despite this also being extremely simple to do from an effort perspective you yourself were saying was unneeded BS just a few comments ago. The relevant text from the GPLv2 itself: > For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. And the busybox license page's comment on this often going awry: > Some companies get in trouble because although they use an upstream vanilla source tarball, they don't say what version it was, or they don't explicitly say it wasn't modified, and they don't include “the scripts used to control compilation and installation of the executable”. Then when we approach them for more information, they don't understand what we could possibly want, and panic. Please don't panic; just work with us.
  - nix23 4y ago
    Moon mission man again: >>3(a) bundle the complete, corresponding source with the binary. >>Using option 3(a), that is, putting exact BusyBox source and .config file you used to build the binary on the same medium which you use to ship the binary, plus "the scripts used to control compilation and installation of the executable" is the most bullet-proof approach to license compliance. If you do that, you can stop reading, your license obligations have likely been satisfied. ->is the most bullet-proof approach ->you can stop reading, your license obligations have likely been satisfied. This is the Link: https://www.busybox.net/license.html https://www.busybox.net/license.html They get angry if you don't make what the license says 1.5 year after they warned you...it's their right to do so. 60% of your comment are just mutated strings of text to fit your narrative. However, BSD/ISC/MIT are the better licenses anyway (for 99%), i don't want lawyers involved in a technical project if possible...also no Stallman's or free beer discussions.
    - zamadatix 4y ago
      This is the page I have been referring to since you wrote "As far as I know, the requirement is to dump a tarball of any changes you made on a web server". Again what's on that page and what you were saying clearly disagreed, just go back and read your original comments now that you understand the distribution requirements. Nobody has been saying the requirements are complicated just easily missed. Despite the message of "if you do that, you can stop reading" imagine you might not always be able to do that and read on through to the following regarding option 3(b) which deals with their recommendation for what to do when you ship the binaries with firmware, the most common method of distributing copies of busybox. 3(a) is the simplest way for general software but it doesn't really make sense for the firmware distribution use case, as they note. Either way both 3(a) and 3(b) are completely different from what you were originally proposing to do and they both requiring delivering full source + build/install scripts even if you don't otherwise redistribute the source (just redistributing the binary is enough). Nothing complicated as long as you can get people to read the license page first. So far everything here but your earlier comments agree many other licenses are easier to comply with and it's not worth worrying about. This is why the original comment recommended looking at Toybox, a BSD licensed alternative, for the reasons you just listed. There's not any need to constantly call names or say responses are BS, the content of each message already speaks to its own value.