Licensing overwhelm, asking for advice

Business and Project Management Discussions
#1

I’m just about ready to post a class, AudioCue, but am really confused about all the complexities around copyright and licenses.

Started by looking at LGPL (“Lesser Gnu Public License”) but their documentation suggests the relatively small amount code might be better served by Apache 2.0 license. So, I was looking at that and trying to figure it all out.

Then, took a look at the MIT license. It is short and simple, and would suffice. The main thing I’m wondering is if it would be okay or reasonable to add a clause that requires including the Project Name and/or a URL where I plan to maintain a copy of the source code as well as a record of revisions as I make them.

Have others done this? Examples of the wording?
Parts in BLUE I added.

OK, here is a possible draft:

I’m now thinking, maybe there is no need to mention that there is a url with source. Someone could probably find their way there via my name and the project name and searching.

#2

Maybe the 3-clause BSD fits into your needs:
https://opensource.org/licenses/BSD-3-Clause

Note that the copyright holder is retained in the notice. Is it enough for you?

#3

Interesting option. I was kind of shocked to see the following listed as one of the three clauses in the BSD-3-Clause

[quote]3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
[/quote]
Do people do that sort of thing?
Is it legal to do that? I mean, maybe the clause isn’t needed if it is illegal for someone to say you endorse something without your permission.
Jeez.

The main thing I’m hoping is that some game programmers find the code useful, using it as a kind of souped-up Clip class. But I’d like some credit as the developer and certainly don’t want to find myself in any sort of situation where I am prevented from using my own code.

#4

Then, you can pick the BSD-2-Clause :wink:

Yes, some people do it. I don’t see how you would be prevented from using your own code.

#5

A while back I went searching for the appropriate license to use and I agree with gouessej, the BSD 3-clause license is the best one for what you want (and mine as well). I’ve used it on all my projects so far.

#6

BSD for the win. Fire and forget.

Cas :slight_smile:

#7

Having three solid endorsements–takes a big load off of my mind.
Thanks!

#8

Nice of you to choose such a permissive license as BSD.
One thing that I’ve always thought was interesting was that you can always relicense to make your code more open, but not the other way around. By licensing permissively, you’ve lost the option to keep the code private.

#9

Well not quite… you can fork your own code and license it differently and it can evolve in its own private way.

Cas :slight_smile:

#10

Good point, new work can be relicensed.
But with old work, once the cat is out of the bag, it’s out forever

#11

I’ll throw in my 2 cents. I’m a fan of the MPLv2 license when aiming to release production quality code open source that I’ve funded with my own money / bootstrapping. I’ve certainly been influenced by the late Pieter Hintjens and enjoyed his book Social Architecture. From his blog and an early draft of the book he has a nice section on licenses and a great story about BSD (MIT and Apache) that certainly informed me on choosing the MPLv2 for TyphonJS and any other open source I release (TyphonRT eventually!). I’m also adopting a modified (info that is technical specifics) C4 contract for governance of all open source repos I release.

From a practical perspective a lot of the work I put out is highly modular where each module follows the single responsibility principle. The MPLv2 works great in this situation. The larger software systems that I’m releasing are all plugin / component based where the runtime is composed of many single modules any of which can be swapped out, but most folks won’t swap out the core modules I make as the 1st party dev, but choose to provide further plugin / module extension for customization.

Interestingly the major Javascript documentation tool that I’m still finishing up (TJSDoc) was forked from ESDoc (MIT) after the author refused to accept outside contributions or discuss / engage anyone in the community trying to participate (fellow is also from Japan and doesn’t understand English, so there is that difficulty too!). The fellow made it clear that it was his hobby project and wouldn’t take outside suggestions small or large or code. I don’t take forking lightly, but this was a case where I forked an MIT project and put in considerable time / money to make a production quality system which is even easier for 3rd party developers to extend amongst many other feature / architecture improvements. To protect this effort (~1500 hours / all programming time this year so far!) MPLv2 fits.

I’d say check out the Social Architecture book for an interesting treatise on community building and licensing / other matters that come into play including a good overview of what a software license actually provides as far as it relates to contract / copyright, etc. If anyone has any other pointers to other treatises in this matter I’d be glad to check them out as I find the topic interesting.

If you don’t have time to check out the above links these two paragraphs cut to the chase:

"BSD is like food. It literally (and I mean that metaphorically) whispers “eat me” in the little voice one imagines a cube of cheese might use when it’s sitting next to an empty bottle of the best beer in the world, which is of course Orval, brewed by an ancient and almost extinct order of silent Belgian monks called Les Gars Labas Qui Fabrique l’Orval. The BSD license, like its near clone MIT/X11, was designed specifically by a university (Berkeley) with no profit motive to leak work and effort. It is a way to push subsidized technology at below its cost price, a dumping of under-priced code in the hope that it will break the market for others. BSD is an excellent strategic tool, but only if you’re a large well-funded institution that can afford to use Option One. The Apache license is BSD in a suit.

For us small businesses who aim our investments like precious bullets, leaking work and effort is unacceptable. Breaking the market is great, but we cannot afford to subsidize our competitors. The BSD networking stack ended up putting Windows on the Internet. We cannot afford battles with those we should naturally be allies with. We cannot afford to make fundamental business errors because in the end, that means we have to fire people."

#12

Thanks for the really interesting links and discussion, @Catharsis!

It has me on the fence again, though. The suggestion of putting a more restrictive license (after making the initial version BSD-type) on a later version is plausible. I am seriously wanting to add cross-fading to loop ends when looping, as well as a random-macro-granule-streaming option. This could be the higher value version.

Here is a thought: Suppose I just retain the copyright for now, but let folks on Java-Gaming.org know that I will grant permission to members to try it out and to use it on a given game. All they have to do is ask me, via PM.

Maybe this is a little overly cautious or control-freaky. But this would perhaps let us know if the code is even worth worrying about, if there is even a problem it solves that matters to Java game makers. (For anyone using LWJGL-derived or JOGL, it won’t be relevant.)

I will make some effort today towards getting a jar posted that can be tried out, and will post it on the Audio thread when I have it set up.

#13

So just make that your license for now.

Cas :slight_smile:

#14

When dealing with licences, I have been using just for the guideline the following service: https://tldrlegal.com/. They got rule-based search and explain with very simple terms the most important points of each licence. Just throwing it here, maybe someone will need.

#15

@philfrei it’s hard to say how strong of a rein to keep on your work. Developer tooling in general is a lost market as there is next to nil chance to “break the market” at this point with a liberal license as the race to the bottom has already progressed thoroughly in this category IMHO. To my understanding if you license with a copy-left variant, but don’t accept any outside contributions you are free to relicense as you chose fit without having to get a unanimous consensus from all contributors. I like MPLv2 as it’s weak copy-left insofar as not imposing the same license requirement on derivative code that incorporates it separately, but keeping the upstream mechanism intact for any modifications to the target given source. For any work that is clear in purpose that does what it is supposed to do MPLv2 essentially fits like a glove. As far as generative audio is concerned there are options available out there already as you might recall my affinity towards SuperCollider and such even though it’s GPL it can be integrated as a separate process / OSC etc. without assuming any viral license exchange, so there are comprehensive free options. Interestingly enough SuperCollider 1&2 was commercial software w/ 3 going GPL, so perhaps an interesting history to examine in regard to audio software as James McCartney / author of SC made a go in the 90s / early aughts from a commercial angle ultimately settling on the commons / OSS; IMHO breaking the market so to speak for state of the art generative / audio engine software.

So far I’ve had two completely different experiences when it comes to hard forking others works. I mentioned ESDoc (MIT) previously and here is the thread which ultimately caused me to fork. For nearly a year I was the only one answering questions on in the ESDoc repo issues which now is mostly silent w/ questions piling up and I also provided fully working minor and major proof of concept improvements that were declined with no reason given.

The other major effort I’ve forked was escomplex with a completely different thread of illlogic leading to a hard fork. escomplex was dying already abandoned by the original author who did all the work and the maintainer at the time was maintainer in name only not doing any work on the project yet ultimately wanted to micro-manage a non-existent dev community. You can read that thread, but the silly thing is that 4 months later that fellow posted he was looking for a new maintainer and his fork was going to be orphaned. Almost immediately there was uptake of my fork though I haven’t publicized it’s existence outside of some yammering on JGO, however I submitted a patch to a large downstream user (Plato); a few other projects took note that Plato somehow supported ES6+ language features and found my module. The original escomplex still has a lot of downloads as older modules / versions depend on it, but uptake was quick with my effort (graph).

I guess I bring up the escomplex project as you’ll find a fair amount of license “zealots” out there that demand a permissive license. When it comes to developers tools though I gather developers just want something that works with a clear integration pathway as well as any legal requirements from businesses / corps. The choice is how much and are you going to control leakage of your work.

About your situation though. The chance of leakage is low. It’s also tough to say there is much of a / any market for Java based audio / engine software that is interfaced via an OOP / Java API. Very few on JGO make a standard living from their Java games with Android being the most likely case / Pascal (orange pixel) comes to mind and I think there is a thread or two on JGO where he talks about his efforts. There is the black swan we all know of course. Sans marketing budget dev tools need a killer app / game to sell the tools and chances are you’ll have to create that killer game and not just be the audio dev tool provider. Do consider some plugin system though as you could release the core system OSS and then potentially charge for specific value added plugins while allowing 3rd parties to create their own.

Another consideration with releasing your software is that if I recall you haven’t worked as a professional developer yet. By releasing your software under any OSS license it will provide a useful data point / proof of competence for any future employer and provide an opportunity for you to discuss it while interviewing. You can’t lose there; I’ve gotten the majority of my jobs from showing code (mainly TyphonRT) I’ve worked on in the past. To that regard though consider getting things up on Github after you’ve decided on an OSS license or really just do it now under a private repo and make it public when ready. Having it online and accessible could get your foot in the door for an interview if so desired sans dev employment history. You’d make this the star of your cover letter, etc.

Anyway I’m glad that you are getting to the point of having something that you want to get out there in a more official capacity! Congrats and get 'er done!

#16

Ok. I have it all posted, using BSD. All the links seem to work.
Will sleep on it, and post on the audio thread tomorrow.
There was a shit-ton of documentation and proofing.
Probably all sorts of dubious choices made.
It is going to go up anyway.

#17

Considering how many of those already exist (including a pretty powerful one in the JRE), I have to concur! There are some niche use cases for Java based audio, such as requiring more flexibility than integration with a native tool like SuperCollider can give you, but I doubt you’ll ever be able to make any money from it. It’s one of those things where if you make it as free as possible, people might use it, but if you seek to charge for it people will just look elsewhere.

Incidentally, speaking of SuperCollider and license, it’s interesting that Processing’s new sound library is based on Methcla - that’s a potentially more lightweight and better licensed option for games.

#18

This code does not aim so high as to be an audio engine or anything like that.
It’s just another version of Clip, maybe a little easier to use (except for limited audio formats), and a little easier to make soundscapes with than Clip.
Aimed for people trying to stay within core Java.