New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

collective licensing #6

Open
wsc1 opened this Issue Sep 10, 2018 · 20 comments

Comments

Projects
None yet
6 participants
@wsc1
Member

wsc1 commented Sep 10, 2018

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

This comment has been minimized.

Member

mewmew commented Sep 10, 2018

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

This comment has been minimized.

Member

wsc1 commented Sep 10, 2018

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

@mewmew

This comment has been minimized.

Member

mewmew commented Sep 10, 2018

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

@mewmew

This comment has been minimized.

Member

mewmew commented Sep 10, 2018

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

This comment has been minimized.

Member

wsc1 commented Sep 10, 2018

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 wsc1 referenced this issue Sep 11, 2018

Closed

zc use questions #27

@wsc1

This comment has been minimized.

Member

wsc1 commented Sep 11, 2018

Just asked @hajimehoshi about go-mp3 here

@wsc1

This comment has been minimized.

Member

wsc1 commented Sep 11, 2018

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

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 wsc1 referenced this issue Sep 13, 2018

Open

Proposed move of flac to github.com/ljud/flac #19

0 of 10 tasks complete
@wsc1

This comment has been minimized.

Member

wsc1 commented Sep 13, 2018

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

This comment has been minimized.

Member

mewmew commented Sep 13, 2018

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

This comment has been minimized.

hajimehoshi commented Sep 13, 2018

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

This comment has been minimized.

Member

wsc1 commented Sep 13, 2018

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

This comment has been minimized.

Member

mewmew commented Sep 13, 2018

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

This comment has been minimized.

Member

wsc1 commented Sep 13, 2018

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

This comment has been minimized.

mattetti commented Sep 13, 2018

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

This comment has been minimized.

Member

wsc1 commented Sep 13, 2018

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

This comment has been minimized.

Member

wsc1 commented Sep 13, 2018

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

This comment has been minimized.

jfreymuth commented Sep 13, 2018

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

@mewmew

This comment has been minimized.

Member

mewmew commented Sep 13, 2018

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

Likewise.

@wsc1

This comment has been minimized.

Member

wsc1 commented Sep 14, 2018

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

@dskinner

This comment has been minimized.

dskinner commented Sep 30, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment