Re: dual licensing (was: Re: [no subject])
Just to make myself clear: if you can't determine sourcecode you still
can't release under the GPL, even if you dual-license.
Andrew
On 11/5/05, Arc Riley <arc@xiph.org> wrote:
> On Sat, Nov 05, 2005 at 06:47:03AM +1100, Andrew Donnellan wrote:
> > >
> > > So if you want, you can use it under the terms of the MIT license.
> > >
> > > And, if you prefer, you can use it under the terms of the GPL license.
> >
> > I mean the *developer* must comply with both licenses, eg if you d/l
> > under the GPL and MIT, then the developer must still put the written
> > offer for source code and meet all the distribution requirements of
> > the GPL, but anyone else can choose between the GPL and the MIT
> > license.
>
> This is true for any developer who releases under both licenses, but any
> developer may release under just one license and then only comply with that one.
>
> In the effort for expanding understanding, here's why that is, by looking at the
> way the GPL works...
>
>
> The GPL has it's legal enforceability from copyright law. GPL'ed software is
> copyrighted, which restricts all but the most fringe fair uses to the software.
> No user has the right to use or redistribute the software in most ways under
> this state of non-license.
>
> The GPL, being a license, also serves as a sort of unsigned contract between the
> two parties. The author, by releasing per software under the GPL, offers in
> writting to provide certain things to 3rd parties, including source code, which
> is what prevents deceptive authors from releasing under the GPL but not
> complying with it themselves.
>
> Then the copyright holder provides a license which permits non-exclusive,
> royalty-free access to the software under certain conditions. We're all
> probobally very familiar with what the GPL provides, so I'll leave it there.
>
> Now, with dual licensing, the copyright holder offers two different licenses.
> The purpose of any license is to permit activity which the copyright, by itself,
> will not. It cannot legally restrict beyond what copyright already does.
>
> Nothing in the MIT license, using this as an example (there's a number of
> proprietary licenses used too, see MySQL or ReiserFS for good examples), says
> you must also comply with the GPL license. Nothing in the GPL license says that
> you must also comply with the MIT license. Therefore, you have a choice, since
> both of these licenses independently grant you access to the code.
>
> If you, as a developer, user, reseller, etc choose to only use one license, that
> is your right, as granted by the original copyright holder. When you slap your
> copyright on your contributions, assuming you're adding or changing it, you may
> choose to only license your changes under the GPL, or under the MIT, as both
> permit changes to be added and redistributed.
>
> Now, most dual licensed software requires that, in order for your changes to
> make it back into the main distro, you must license under both licenses. Some
> also require that you give the copyright of your changes to the original author.
>
> See reiserfsprogs/README for an example of this, where you're allowed not only
> to keep your copyright but, if you dual license for commercial/proprietary sale
> (ie, company wants to use reiserfs in non-free software) he may cut you a check
> for non-trivial contributions.
>
> None of this is required. You can, in the above example of GPL+MIT, release a
> fork of the code under the GPL exclusivly (or MIT exclusivly) if the author
> won't accept your contribution unless it's also dual licensed. That is, if you
> write a really great new optimized search routine for MySQL but you don't want
> your additions to be anything but GPL, MySQL won't accept it, but that doesn't
> mean you can't offer a fork or patchset for others to use.
>
>
> Now, having a single software package where two or more different licenses cover
> different parts of the code is a different issue, one that was hinted to earlier
> on the thread. In this case, those licenses apply only to the parts of the
> package which they cover, and this may or may not be in violation of the GPL
> depending on how those pieces "fit together". If they're ment to be compiled
> into a single binary, or linked against each other, and the licenses aren't
> compatable, the maintainer for that package needs to be "schooled".
>
> It's perfectly fine, however, for a library to be released under a BSD license
> with an example mini-app which uses the library licensed under the GPL and
> documentation licensed under the FDL (or CC Attrib-AsIs or any other combo).
> A GPL'ed application can link against BSD-licensed library and the docs, which
> are entirely seperate, can be licensed however the author chooses.
>
> A similar situation can arise from patent licenses, which are similar but of an
> animal all their own. If the patent license (a license which grants access to
> some patented method or procedure) is GPL-incompatable the author must be very
> careful that whatever software implements it not be linked directly against
> either the GPL or LGPL, as section 7 of the GPL and section 11 of the LGPL would
> render such software illegal for 3rd parties to distribute, as enforced by the
> copyright holder. While the author perself may not sue someone over this, any
> 3rd party contributor/copyright-holder who licenses their contribution under the
> (L)GPL may, and that's politically bad for all of us.
>
>
> More than you probobally wanted to know on the subject, but hope it clears up
> all the confusion on the issue. :-)
>
> --
>
> Diversity is the Fuel of Evolution,
> Conformity its Starvation.
> Be Radical. Be New. Be Different.
> Feed Evolution with Everything You Are.
>
>
> --
> To UNSUBSCRIBE, email to debian-legal-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
--
This space for rent. Enquire within. Terms and conditions apply. See
store for details.
Get free domains - http://www.ezyrewards.com/?id=23484
Reply to: