collective licensing

[wsc1]

There are a lot of existing Go projects whose involvement and interoperability with zc would create synergy. ZC has a 3-clause BSD shared author license, which is in the form of Go. However, it seems most projects use Apache 2.

This issue is to invite discussion on the possibility of changing the license of zc to Apache or somehow offering both Apache and 3-BSD shared author licenses. If zc had a shared author Apache license, it seems it might be easier to arrive at a single collective license which more components could be distributed under.

[mewmew]

Would be interested if you listed the specific repositories that you have under consideration, so that we may invite those authors to the discussion directly, and also list what each project has for license.

[wsc1]

Yes can do that, I'd be interested if you did the same as well.

[mewmew]

I'm only using FLAC and WAV encoders/decoders, so will list those below:

• FLAC
  • github.com/mewkiz/flac: public domain
• WAV
  • github.com/azul3d/engine/audio/wav: BSD 3 clause
  • github.com/go-audio/wav: Apache 2.0
  • github.com/zikichombo/codec/wav: BSD 3 clause

[mewmew]

I don't think there is an issue to keep this code base in BSD and still use projects being in Apache and vice versa.

See: https://www.apache.org/legal/resolved.html#category-a

Works under the following licenses may be included within Apache products:

• BSD (without advertising clause). Including variants:
  • BSD 2-clause
  • BSD 3-clause

[wsc1]

I'm no lawyer and so tend to proceed with caution

"you can include BSD 3-clause under apache license" goes in only one sense. Where did you see the other sense?

Also, such imports would place the licenses under mixed author, mixed license. Although we can research and verify that that is ok with what we want, and present something simple to consumers, it is still perhaps more complicated than necessary.

For the research, I didn't see in your apache link anything about difference in patents, for which IRI France, SAS could provide the equivalent of the Google Go Patent grant for zc or adopt APACHE, which has patent protection (maybe stronger protection than Google Go Patent grant to my understanding). In fact, it seems not having patent protection for IFS is a liability that would be nice to address.

Other APACHE licensed audio code:
webm parser
sigourney (although zc doesn't have any midi synth related tools or know-how at present)
most of what I've seen in go-audio
most of what I've seen related to android Audio (such as github.com/google/oboe)
go-mp3

Other licenses
github.com/faiface/beep: MIT
jfreymuth ogg/vorbis: MIT

All these licenses are similar in spirit to me. But compatability still scares me due mostly to patents but also to the fact that once we start considering a set of licenses, it indicates we may change that later and so may scare off some potential consumers who might think our idea of what is ok might stray outside theirs.

At the same time, IRI France SAS disposition w.r.t. to all this is to work by consensus of those involved. At present, IFS's name is on the collective license in more pronounced way, like Google in the Go license. Apache shared author license differs in this respect, placing all authors under the same conditions. Some may prefer that, and it would also be more reflective of the IFS disposition to work by consensus.

For info, earlier, @mattetti suggested to keep the list at MIT/Apache.

[wsc1]

Just asked @hajimehoshi about go-mp3 here

[wsc1]

I'm only using FLAC and WAV encoders/decoders, so will list those below:

• FLAC

  • github.com/mewkiz/flac: public domain

• WAV

  • github.com/azul3d/engine/audio/wav: BSD 3 clause
  • github.com/go-audio/wav: Apache 2.0
  • github.com/zikichombo/codec/wav: BSD 3 clause

It looks to me like both azul3d and go-audio wav support more wav functionality than zc/codec/wav.
moreover, they support different things. So hopefully zc/codec/wav can use or work from those implementations.

[wsc1]

Would be interested if you listed the specific repositories that you have under consideration, so that we may invite those authors to the discussion directly, and also list what each project has for license.

And of course, (I didn't see earlier) there is the GitHub.com/ljud organsition planned.

[mewmew]

And of course, (I didn't see earlier) there is the GitHub.com/ljud organsition planned.

Like the flac lib, anything my brother and I develop we release into the public domain.

[hajimehoshi]

Note that public domain might be problematic in some countries since the license might not be valid as a legal contract: https://opensource.stackexchange.com/questions/5736/sqlite-is-illegal-in-germany-really

[wsc1]

And of course, (I didn't see earlier) there is the GitHub.com/ljud organsition planned.

Like the flac lib, anything my brother and I develop we release into the public domain.

Is this a disposition against participating in a collective license that is not public domain, or just a preference for how you release your work independently of collectively deciding an open source license?

[mewmew]

Is this a disposition against participating in a collective license that is not public domain, or just a preference for how you release your work independently of collectively deciding an open source license?

Just a preference. BSD, MIT, Apache works well also.

[wsc1]

Note that public domain might be problematic in some countries since the license might not be valid as a legal contract: https://opensource.stackexchange.com/questions/5736/sqlite-is-illegal-in-germany-really

I read somewhere that Free software foundation/GPL recommended a standard wikipedia license for public domain grants for legal reasons I don't understand.

[mattetti]

I don't think it's an issue, Apache and BSD are commonly used licenses that people use together all the time. I say keep going until we find a real issue with the license

[wsc1]

Note that public domain might be problematic in some countries since the license might not be valid as a legal contract: https://opensource.stackexchange.com/questions/5736/sqlite-is-illegal-in-germany-really

Yes, some research I did (sorry lost the links) indicated that, for example the FSF recommended the CCL

I don't think it's an issue, Apache and BSD are commonly used licenses that people use together all the time. I say keep going until we find a real issue with the license

I see 2 "real" issues now.

1. licensing complexity of different repos interoperating would scare me off right away were I interested in commercial redistribution.
2. (from above) "In fact, it seems not having patent protection for IFS is a liability that would be nice to address."

Second, it may be harder to address later, as a larger consensus would have to be reached.

[wsc1]

After reading everyone's comments,

I propose to

1. Relicense ZC under apache 2.0 shared author with same authors to adapt to the most common use case according to our research and give IFS patent protection.
2. To advertise/publish in the various zc places that zc guarantees MIT/Apache 2/BSD + host supplied imports transitively (host usually imported via CGO). BSD would be 2 or 3 clause variants.
3. To facilitate cross-repo and organisation importing, to add when necessary an "ImportedLicenses" file to a repo which could contain a list of imported repos and their licenses. A PR or a commit from a maintainer of a repo that zc imports adding to this list would document the commitment on the part of the maintainer to abide by the stated license transitively (amongst Apache 2,MIT,BSD 2 clause, BSD 3 clause) and coordinate with zc in case of any issue about licensing involving zc.

To me, it seems that would facilitate collaborations, guarantee simple licensing, and provide IFS with standard open source patent protection. It would also be less risky than waiting, when doing this might be harder.

For 1) zc would need the explicit approval of @mewmew, and possibly @jfreymuth if he wants (ext only).
For the rest, I will await feedback but might proceed within a few weeks in the case of absence of responses, taking it as tacit approval.

[jfreymuth]

I'm fine with the code I contributed being relicensed under any permissive license.

[mewmew]

I'm fine with the code I contributed being relicensed under any permissive license.

Likewise.

[wsc1]

just in case he wants to follow, this is a ping to @nf

[dskinner]

Referencing 4.4 of the apache license: https://www.apache.org/licenses/LICENSE-2.0#redistribution

You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

This allows one to license a derivative work based on the original work under a license other than the original work. This is an explicit statement in the apache license for what's otherwise implicit in the bsd license.

Note that zc is not even a derivative work since you are not altering the work being imported, so it would suffice to then only fulfill 4.1 of the apache license for redistribution purposes.

This can be done via a NOTICE file listing the apache-licensed libraries there-in.

This NOTICE file should not be confused with the one mentioned at the beginning of 4.4 because zc is not apache licensed, it's simply a convention. Even if zc was apache licensed, the license does not require the NOTICE file. One is only provided as a matter of policy: http://www.apache.org/dev/licensing-howto.html#overview-of-files

By providing a NOTICE file, zc would be redistributing the apache licensed code under a bsd license if and only if zc was actually distributing something.

If zc distributed a shared library with a bsd LICENSE and said NOTICE, the entirety of that shared library is licensed under bsd solely.

Where the hangup occurs is that this will never likely be the sole case for zc distribution. To be a good citizen to the importers of zc, providing a collection of attribution notices for 3rd party libraries used by zc and the requirements said importers must fulfill when importing zc for their end product would be ideal just as one wants to provide a good api for the importer to code with.

One could write a nice little message stating all this but there's not legal force behind it, plus that language is already in the apache license.

More simply, zc could simply be licensed under apache and ask importers to comply.

Providing a NOTICE would assist importers in their redistribution efforts so they are not having to compose this themselves based on reviewing each zc import before distribution. The creation of this file also creates a legal obligation for zc to keep this NOTICE up-to-date.

Consider also LICENSE should be updated with permissively-licensed dependencies: http://www.apache.org/dev/licensing-howto.html#permissive-deps

Then as an importer of zc, I can simply bundle zc's NOTICE and LICENSE and still distribute under whatever license I want while complying with all transitive dependencies.