8

I frequently create programs to process my local files in some fashion. About half of them are Bash shell scripts under 100 lines, others may be longer, include multiple files, or even be in other script languages, such as PHP (PHP License) and Perl (Perl Artistic License, or GPL v1+), or full-on programs in C {gcc, et al.} (GPL v3), Java {Iced Tea} (GPL v2 + Classpath), etc. As I modify them over time I track my work in a local git, sometimes adding the "project" once I realize it's been modified a few times already, or when I think I'm likely to modify it later.

With rare exception, the only third-party resources used in the Bash scripts are system CLI tools (awk, grep, find, etc.), I do have one larger project which uses ffmpeg (LGPL v2.1+) and might use vobsub2srt (GPL v3) and BDSup2Sub (Apache v2), which is a Java .jar. My other projects seldom go beyond the basic modules/libraries for the language. So far as I know, none of what I've used is utilized in a fashion that would make their license infect my projects. As in, any module/library I use could easily be replaced by another one without loss of functionality, similar to choosing a font to use in a document.

As I understand the licensing, none of my uses for third-party resources affects (infects?) my licensing options. If I am incorrect, or borderline, in some case, a word-to-the-wise would be good.

These programs are useful to me, and likely not of much use to others, as-is. In some of the cases, however, there might be content useful to others - either for how I approached the problem or the algorithm I used to create the solution. Moving my local git to GitHub is simple enough. Doing so will allow others to view them, and use whatever is useful to them for their own situations. I also don't expect, or anticipate, that there will be any sort of "collaboration" or contribution from other in developing or improving these projects.

The primary purpose for placing my work on GitHub is to share with others freely. In the case where someone uses a significant portion (whatever that means) of my work in some redistributed work, I'd like to get recognition for my work, while just using a few lines, or the basic concepts of the work-flow shouldn't require them to create a whole new attribution file, or add a bunch of comment lines, "just because they saw my methods."

A secondary purpose for posting the repos is to provide a collection of my work to which I can refer others. At some future date I may become interested in coding for others, and they could view my repos as a portfolio of past work. Granted, the limited scope of the projects so far wouldn't demonstrate much beyond boredom, it would still be a nice idea.

So far, because of the license issue, I have not done so with any significant work. My only GitHub repo thus far is of an answer I posted on SO. (I guess that's now dual licensed: the MIT I applied on GitHub and the CC-BY-SA from the SO posting.) With that exception, all projects are undistributed, in any fashion, though they are in various stages of development.

What I want the licensing to achieve is to make the content usable, most likely by inclusion in larger projects, to the widest audience, while still retaining my copyright and being attributed as the creator when used (no "CC0" or "public domain" options). I've gathered that material distributed under some set of licenses cannot be included in projects covered by some other set of licenses, and avoiding that "lock-out" is the largest of my confusions with the license choice. One way around that, which may not be compatible with the GitHub system is dual licensing of my projects. I suppose it's possible to create two GitHub accounts and list each project twice, once in account "A" with license "One" and again under account "B" with license "Two". That seems like a rather extreme measure, however.

Which license, or license scheme, allows my code to serve the most good?

  • 100% off topic but I never considered storing all of my little helper scripts in source control. thank you for the idea! – Marie Jul 16 '18 at 15:48
  • @Marie Welcome to the site. Look around and see what you like. I'll admit I've never joined a site just to leave a comment. Answers yes, comments, nope. I'm still unsure how I'm going to do this, though. – Gypsy Spellweaver Jul 16 '18 at 15:56
  • I am pretty active on other SEs, I didnt actually know this one existed until it popped up on hot. I know it likely doesnt help but I personally use a private Gitlab repository. I dont share my code often enough that I am super worried about licensing so I have that conversation on a case by case with anybody I share a link with – Marie Jul 16 '18 at 16:01
9

This might take a while, your question isn't a short one, and it seems to me to have a number of misconceptions in it.

I frequently create programs [...] in other script languages, such as PHP (PHP License) and Perl (Perl Artistic License, or GPL v1+)

The licences you quote are those which apply to the languages themselves. With the exception of a very few language compilers which copy part of themselves into the compiled output, the license on the compiler/interpeter has no effect on the licence of your compiled program. You can compile your own code with gcc and then release it under a proprietary licence.

With rare exception, the only third-party resources used in the Bash scripts are system CLI tools

It is generally accepted that when one program calls another through simple fork-and-exec (as your bash script calls awk/grep) they remain separate programs for the purposes of copyright and licensing. You can write a bash script that calls GNU grep, and distribute that script under a proprietary licence. If you distribute the grep binary as well you will have GPL obligations with respect to the grep code, but they are very unlikely to bleed into your code.

I do have one larger project which uses ffmpeg (LGPL v2.1+) and might use vobsub2srt (GPL v3)

Here the detail of how you use them becomes important. You say:

none of what I've used is 'linked' in a fashion that would make their license infect my projects

Linking is a term of art used in computing which has a very specific meaning, and this meaning is not the one used in everyday speech; I am using it in its computing sense. The act of linking, and the method of linking, are an important part of deciding whether a new work is a derivative of some other pre-existing work. The precise conclusions to be drawn remain a matter for debate, as you will find if you follow that link, but what constitutes linking is not a matter for debate. If you use third-party resources through fork-and-exec, you're very likely not making a derivative work. If you link to third-party code, there is at least a strong possibility that you are making a derivative work. The implications of you having made a derivative work depend on the licence on the third-party code, and are too long and variable to discuss here, but if you use third-party code in a manner that is not permitted, you are committing copyright infringement.

any module/library I use could easily be replaced by another one without loss of functionality, similar to choosing a font to use in a document.

I don't know where you got the idea that this is relevant to the decision about whether you're committing copyright infringement. If I choose to use a large piece of Oracle's java code in my project, the fact that I could have used OpenJDK code instead will not save me from Oracle's lawyers.

What I want the licensing to achieve is to make the content usable, most likely by inclusion in larger projects, to the widest audience, while still retaining my copyright and being attributed as the creator

This is a matter of opinion, and therefore likely off-topic; it's also a hotly debated issue. My own feeling can be summed up in one line, arrived at after many painful debates with my BSD-favouring co-author: weak copyleft licences (eg BSD, Apache) are best at making software free; strong copyleft licences (eg GPL, AGPL) are best at keeping software free. I favour the latter class of licences, and along with many other people and organisations I hope you will use them; but there are lots of very bright people who favour the former licences, and their arguments are also well-worth listening to. Here is probably not the place to do it.

  • Re linking: I quoted 'linked' since nothing is linked in the computer sense. Even the use of ffmpeg and the other possible programs are fork-execute. – Gypsy Spellweaver Jul 16 '18 at 7:49
  • The replaceable nature is based on that 1) it's not "in" my code, only called by it, and 2) somewhere, somewhen, I recall that for some license, how "dependent" one program is upon another was an issue for combined vs aggregate. – Gypsy Spellweaver Jul 16 '18 at 7:51
  • Thank you for clarifying that! The way you immediately followed the use of 'linking' with that odd comparison to fonts made me worry that misunderstandings were occurring. I strongly recommend you not use the term linking, then, since that already has a very clear and well-defined meaning, and this meaning is important to the question of creating derivative works. – MadHatter Jul 16 '18 at 7:52
  • 1
    The final paragraph touches dilemma well. I support strong copyleft as a principle, while recognizing that "principle" is not good eating, or useful in paying bills. I'd like to keep the code free, but not so "free" that it cannot be used. – Gypsy Spellweaver Jul 16 '18 at 8:01
  • 6
    @GypsySpellweaver I hear you. For me, the problem is that code that is made quickly free, with the ever-popular weak copyleft licences, can just as quickly be included in a proprietary product, and indeed it often is. It has long seemed to me that if you want to keep code free, if your concern is maximum user freedom, the strong copyleft licences are the way to go. If you're concerned about maximum utility, the largest-possible number of people using your code, then weak copyleft is the way to go. It's your code, so you get to decide what's most important to you. – MadHatter Jul 16 '18 at 9:01

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.