[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Patch Licensing Terms
- From: Coda Highland <chighland@...>
- Date: Sun, 26 Nov 2017 20:39:56 -0600
On Sun, Nov 26, 2017 at 7:30 PM, szbnwer@gmail.com <szbnwer@gmail.com> wrote:
> ive heard that one can double license or relicense their product, but
> im not sure if its true or it have any requirements different than
> what was at the beginning - so ive interpreted this as i can use gpl
> and then give mit for the upstreams for the needed parts, but the
> whole would "downgrade" the gpl... and for sure only if ive made it
> gpl without include gpl code from any other project
It sounds for the most part like you understand things correctly, but
to summarize:
If you're the sole author of the code in question, you're permitted to
put whatever the heck license you want on it.
The big catch is that if some parts of the code you created are
derived from other code that you didn't write, then you might still be
beholden to that license. (There's a bit of a flame war surrounding
whether subclassing counts as non-fair-use derivation.) But all of the
parts that you created completely by yourself are still owned by you,
and if you edit out the stuff that you made by modifying other
people's stuff, you can do whatever you want with it.
That said, anyone who received the code under the old license still
has permission to use that code under that license -- unless otherwise
stated, licenses are non-revokable. This doesn't entitle them to use
future releases you may create under the old license (they have to
accept the new license to update) but the old version is still going
to be out there.
So if you make patches to upstream components, the license on the
upstream components is what applies there, since you're modifying the
upstream source. You can put other restrictions on your patch if you
want as long as they don't conflict with the original license, but
this is generally a bad idea because it means that upstream can't
ACCEPT your patch. :P
> putting together gpl with other (and compatible) stuffs makes the
> other stuffs gpl as well but what about (lets say) use luakit (gpl)
> write a library that is exclusively used with it but not strictly
> related so not calling anything from it but luakit using it and its
> kinda related to browsing but could be freestanding... - if its in its
> own file then i can simply give it an mit?
You can, yes. The resulting combined work would be under both the GPL
and the MIT and people distributing it would have to comply with both.
(But since they're compatible the only requirement is that you have to
keep the text of the MIT license attached to it when you distribute
it. This is easy because you just put it in a comment at the top of
the file.)
> what about linux, that is under gpl if im right, and there are apps
> with various licenses above it that are calling the kernel? its just a
> well separated unit?
In theory, you're basically right here. You've gotta watch out because
some system libraries might be GPL and if you use those then you're
GPL too. Fortunately, glibc is LGPL so you can use glibc and still be
non-GPL yourself.
> sorry if this one is bullshit, but ive heard that one can run a gpl
> (or what else?) stuff on bsd but not vice versa, or what is the point
> where incompatibility of allowing/declining binary distribution blocks
> the road?
As the end user, you can run anything you want on anything else you
want. The licensing requirements come into play when you're talking
about redistributing the software.
> and yes, id also like to make an alpha release in a closed circle with
> additional licenses, and im also afraid of evil guys out there that
> will poison my stuffs with the wrong aims and contents and contexts
> and whatever
You have that right as long as you don't distribute something that
incorporates copyleft material. If you really need to use GPL stuff,
you're basically stuck distributing source and saying "build this
yourself, the combined output can't be distributed".
/s/ Adam