[License-discuss] Source-attribution licenses and Javascript compatibility

Tue May 31 18:25:47 UTC 2016

I agree completely with Philippe; a statement such as you proposed does not
modify the license, but it indicates to downstream consumers the scenarios
under which they could expect you to (potentially) enforce the attribution
requirement, and situations under which you do not intend to enforce the
attribution requirement. As the copyright holder, you are certainly free to
give your licensees broader permissions than the zlib license already gives
them and doing so should not affect OSI's blessing of the license. For
example, there are a quite a few projects licensed under GPLv2 or GPLv3
which also grant permission for linking with OpenSSL, which is necessary
due the license incompatibility which would otherwise exist.

If you expect that in the future you might receive contributions to your
projects from other copyright holders, you'll need to ensure that they
understand the licensing situation as you've described it, and that they
also agree that attribution is not required in cases 2 and 3. This might
require explicit acknowledgement on their part in some form.

On Sat, May 28, 2016 at 2:45 PM, Philippe Ombredanne <pombredanne at nexb.com>
wrote:

> On Fri, May 20, 2016 at 4:06 AM, Andi McClure <andi.m.mcclure at gmail.com>
> wrote:
> > I am working on some projects (a programming language, a game library)
> for
> > which I wish to use a "source attribution" license-- for example, the
> zlib
> > license, or the 2-clause BSD license if I could somehow delete the second
> > clause. I want people redistributing or reusing source code from my
> project
> > to keep attribution along with the source; however, I do not want to put
> > conditions on people who are only distributing executable versions to be
> run
> > by end users.
> >
> > However it is ambiguous to me what "source" and "executable" mean when
> > dealing with interpreted languages, or in particular when dealing with
> > Javascript, which has developed an entire tools ecosystem around
> > "minifying". Consider these scenarios:
> >
> > 1. A developer has taken a Javascript library I wrote and embedded it
> into a
> > web app they wrote using a <script src> tag. (The .js source file is
> vended
> > from their web server, but never made directly visible to the end user.)
> >
> > 2. A developer has used node.js, uglify.js and webpack to "compile" a
> > Javascript library I wrote, along with their own code and other
> libraries,
> > into a single large .js file. The code is dense, not human readable and
> is
> > basically obfuscated.
> >
> > 3. A developer has used a transpiler like Emscripten to compile a C
> library
> > I wrote into dense, non-human-readable Javascript code.
> >
> > 4. A developer has written a program in Lua, an interpreted language.
> They
> > distribute this as a .exe containing an embedded Lua interpreter. They
> pack
> > all the Lua code their program uses, including a Lua library I wrote,
> into a
> > .zip file and distribute this .zip along with their .exe (possibly
> literally
> > packed into the binary of the exe itself).
> >
> > These are all real, non-hypothetical ways of using open source code (I
> have
> > done all of them myself) and I do not think I know how to apply the zlib
> > license to any of these.
> >
> > The zlib license refers to "source distributions". The BSD license
> refers to
> > "redistributions of source code". Neither license defines "source code".
> > Without a definition, how do I (or someone who uses my project) know
> whether
> > cases #2 and #3 are "source distributions"? Cases #2 and #3 are literally
> > distributing Javascript source, although it is no longer the source to
> the
> > original program.
> >
> > The Apache and MPL licenses *do* define "source code" (both say something
> > like "the form of the work preferred for making modifications"). Both of
> > these licenses are more restrictive than I want to use, but the
> definition
> > at least means the license is unambiguous, and clearly with these
> licenses
> > cases #2 and #3 are not "source distributions". If I had a license which
> > excused attribution in the case of #2 and #3, but required attribution in
> > the case of #1 and #4, I think I would feel satisifed since I assume in
> > cases #1 and #4 one could satisfy the license by simply leaving comments
> in
> > the source files (#2 and #3 are awkward this way because the
> > javascript-packing process naturally strips comments).
> >
> > Is there a existing source-attribution license which fits my needs here?
> >
> > Would it be sufficient to use the zlib license and then outside the
> license
> > include a clarifying paragraph like:
> >
> >     "For purposes of the above license, 'source' is defined as the
> preferred
> > form for making modifications to the code. In other words, minified
> > Javascript which is not intended to be modified does not count as a
> 'source
> > distribution'."
> >
> > …and if I included such a clarifying paragraph outside the license,
> would I
> > break the magical spell of OSI compliance which zlib normally has?
> >
> > Alternately, would it make sense to introduce a new license for this
> > purpose? It seems like the javascript ecosystem is really hurting for an
> > appropriate license, and this is a real need which should be filled at
> some
> > point. My impression from my brief experiences with modern javascript
> > development is many of the people using webpack are not bothering to fill
> > their license requirements (ie using MIT licensed libraries but not
> > surfacing license information anywhere).
>
> If I were in your position with the parameters you laid out I would
> probably:
> 1. use the zlib license
> 2. outside of the license, I would create a FAQ to clarify what my
> definition of source code is.
>
> This way you would not create a new license and you still make it
> clear to users what is your understanding of the the meaning of source
> code. For instance listing as FAQ entries the four cases you list
> above. The same way there is a digest version of CC licenses that is
> not the license and the FSF has a GPL FAQ which is not the GPL.
>
> FWIW, I would consider your #1 and #4 as source code and #2 and #3 as
> binaries. To me, transpiled or minified source is similar to any
> traditional "compiled" binary: and in most cases it is as opaque as a
> binary.
>
> --
> Cordially
> Philippe Ombredanne
>
> +1 650 799 0949 | pombredanne at nexB.com
> DejaCode : What's in your code?! at http://www.dejacode.com
> nexB Inc. at http://www.nexb.com
> _______________________________________________
> License-discuss mailing list
> License-discuss at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20160531/d296f407/attachment.html>