zc use questions

[wsc1]

Hi,

I Am curious about usage of go-mp3 in zikichombo.org/codec or zikichombo.org/ext.

Some questions about how this might be done, or if it is appropriate.

1. Do you intend to keep it pure Go?
2. zc currently has a standard shared author BSD license, and we are careful about transitive licensing via imports, as is being discussed here

Best,
Scott

[hajimehoshi]

Hi,

Do you intend to keep it pure Go?

Yes.

zc currently has a standard shared author BSD license, and we are careful about transitive licensing via imports, as is being discussed here

Not sure what was the question. I think using BSD lib and Apache v2 lib should not be problematic (disclaimer: I'm not a lawyer or a professional in the laws, so don't take this a legal advice).

[wsc1]

For licensing question, zc is trying to decide what to do, you are welcome to participate in general in that and it may effect how go-mp3 can be used in zc.

For go-mp3 usage w.r.t. licensing, no lawyer here either. But, there are many things we consider:

1. zc support may be supplied by an arbitrary package such as go-mp3. It's probably just a thin wrapper. zc has a standard BSD shared author license. But moreover, we take care to only import either Go std lib or host (OS) things. There are no license questions other than the above for importing zc.

2. zc could import go-mp3 subject to allowing us to maintain the constraints in 1) above. That would require a licensing agreement with you. Given the collective licensing discussion which you are welcome to join, the constraints 1) above may change to being for example that zc is re-licensed under Apache v2 lib.

3. zc could import go-mp3 in a special "ext" repo where we don't guarantee the licensing constraints in 1). Code in zc/ext is under less overall control and coordination and licensing multiplicity (and transitivity) issues are a burden or potential burden on zc consumers. As a result, zc has a preference for proceeding by 1) or 2) above.

Just stating that go-mp3 is apache v2 lib doesn't say anything about licenses of what go-mp3 imports or may one day import, so it's not good enough to use in zc beyond option 3), which limits its users.

So, in short, the question is, which of these things would be best for you and go-mp3?

[hajimehoshi]

That would require a licensing agreement with you.

You don't have to agree with me as long as you obey Apache License 2? (Or, if you meant 'to agree' is to obey the license, that's fine). I'm still not sure what is the problem, but wouldn't putting a document somewhere that says go-mp3 is Hajime Hoshi's Apache License 2 lib enough?

[wsc1]

For context, I said:

1. zc support may be supplied by an arbitrary package such as go-mp3. It's probably just a thin wrapper. zc has a standard BSD shared author license. But moreover, we take care to only import either Go std lib or host (OS) things. There are no license questions other than the above for importing zc.

2. zc could import go-mp3 subject to allowing us to maintain the constraints in 1) above. That would require a licensing agreement with you.

You asked:
You don't have to agree with me as long as you obey Apache License 2? (Or, if you meant 'to agree' is to obey the license, that's fine). I'm still not sure what is the problem, but wouldn't putting a document somewhere that says go-mp3 is Hajime Hoshi's Apache License 2 lib enough?

I try to clarify:

There are 3 options for go-mp3 to work with zc. I think you are asking about option 2. This option would mean there would be a copy of go-mp3 in zc under zc license. Such a copy of go-mp3 would also need to conform to zc import guarantees (only importing zc, Go stdlib, and OS-supplied libraries). Of course, there could be a document stating that such a copy of go-mp3 comes from Hajime Hoshi's go-mp3 under Apache License 2 lib, and you could be the owner and control the code, but the license for a copy of go-mp3 in zc would be different than the license in github.com/hajimehoshi/go-mp3. The purpose of having a copy of go-mp3 like this is so that zc can guarantee to its consumers the zc (BSD) license and import licensing policy.

If that is not interesting to you, would option 1) be?

If neither option 1 nor option 2 are interesting to you, we will probably try to import go-mp3 under zikichombo.org/ext, which is a special place for collaborating that places liability of organising and checking licenses of transitive imports on the consumer.

Scott

[hajimehoshi]

I don't have a strong opinion which 1) or 2) is preferable to me. 1) sounds slightly better since it doesn't require code duplication. I understand you are trying to create a thin wrapper of go-mp3, but in the first place, I was wondering what problem you are trying to solve by create the wrapper. People would still be able to use my go-mp3 directly.

[wsc1]

The wrapper would enable interoperability with the rest of zc. For information on the scope and
functionality of that, see the website

[wsc1]

sorry, didn't mean to close

Will wait for you to digest what zc interop will provide to finalise deciding between 1,2,or3.

[hajimehoshi]

For interoperability, 1) should be the best. You are worried about the license complexity of your project even though there is no legal problem?

[wsc1]

Also, for option 2, I said at first "zc could import go-mp3" and later "a copy of go-mp3 would be in zc under zc license". This is just a result of there being different ways to get zc license + import policy with go-mp3. The copy could be anywhere, such as maybe a branch of go-mp3, but it would have to conform to zc license + import policy. Later I assumed it would be easiest to do that within zc in order to explain with a concrete scenario.

[hajimehoshi]

Also, for option 2, I said at first "zc could import go-mp3" and later "a copy of go-mp3 would be in zc under zc license".

Even if you copy go-mp3, the copied project is still under Apache License 2.0. I still don't understand why it is not an option to put a document under your project that says "go-mp3 is under Apache License 2.0".

[wsc1]

Also, for option 2, I said at first "zc could import go-mp3" and later "a copy of go-mp3 would be in zc under zc license".

Even if you copy go-mp3, the copied project is still under Apache License 2.0. I still don't understand why it is not an option to put a document under your project that says "go-mp3 is under Apache License 2.0".

Sorry to not be clear. (*) All of ZC (except zc/ext) guarantees importers of zc that all code is under shared author BSD license, that all code only imports Go standard lib and host supplied code (via CGO usually).

If ZC did as you suggest, then zc would have to have multiple licenses, and could no longer guarantee (*). It has nothing to do with Apache vs BSD or compatability for that combination. The problem for ZC would be the multiplicity of licenses. If ZC just added licenses like you suggest for go-mp3, then that would set a precedent that maybe tomorrow there will be an mp3 encoder in ZC under MIT, or Unlicense, or in the public domain. Or maybe GNU LGPL. Doing what you suggest is in general not simple and can scare off potential users when you consider that ZC deals with multiple contributers/suppliers.

We can, however easily do as you suggest in the module zikichombo/ext, or just import github/hajimehoshi/go-mp3 from there. That is because zc/ext is a designated place for consumers of zc to verify licensing for themselves.

Or github.com/hajimehoshi/go-mp3 can import zikichombo.org and support it there.

[wsc1]

Also, for option 2, I said at first "zc could import go-mp3" and later "a copy of go-mp3 would be in zc under zc license".

Even if you copy go-mp3, the copied project is still under Apache License 2.0.

Of course, only the copyright owners have the right to create or authorise a copy under a different license.

ZC is also considering changing to Apache 2. Your input there can influence that.

[wsc1]

For interoperability, 1) should be the best. You are worried about the license complexity of your project even though there is no legal problem?

Worried about license complexity so as to avoid fears of legal problem and work related to verifying that.

Ok, should I go ahead and add a plan for a PR to add zc support to go-mp3 by means of a wrapper?

[hajimehoshi]

OK so you are worried about the license complexity. However, even if you persuade me to change the license of go-mp3, you still would need to persuade other lib owners whenever necessary, then I don't think this is a general solution. This would be same even if you change zc's license to Apache 2 (what if other libs you want to use are NOT under Apache 2?)

Or github.com/hajimehoshi/go-mp3 can import zikichombo.org and support it there.

I'd not want to do that. I was wondering what is the benefit to me.

[wsc1]

OK so you are worried about the license complexity. However, even if you persuade me to change the license of go-mp3, you still would need to persuade other lib owners whenever necessary, then I don't think this is a general solution. This would be same even if you change zc's license to Apache 2 (what if other libs you want to use are NOT under Apache 2?)

Yes, but there appears to be more Apache 2 than BSD in this space.

Or github.com/hajimehoshi/go-mp3 can import zikichombo.org and support it there.

I'd not want to do that. I was wondering what is the benefit to me.

I thought you said you preferred option 1 for interop? that was go-mp3 importing zc Now I am confused.

Again, the benefit is interoperability with the functionality described at Zikichombo.org.

[hajimehoshi]

I thought you said you preferred option 1 for interop? that was go-mp3 importing zc Now I am confused.

1 means to change go-mp3 to import zc? Sorry but I was misunderstanding. I thought 1 is that zc imports go-mp3.

Again, the benefit is interoperability with the functionality described at Zikichombo.org.

I'm asking the benefit to me.

[wsc1]

I thought you said you preferred option 1 for interop? that was go-mp3 importing zc Now I am confused.

1 means to change go-mp3 to import zc? Sorry but I was misunderstanding. I thought 1 is that zc imports go-mp3.

Sure, we can do 1, but it would require an agreement between you and zc that go-mp3 would provide zc licensing and import guarantees.

Or we can do 3 and let consumers deal with verifying licensing and imports.

[hajimehoshi]

1. zc support may be supplied by an arbitrary package such as go-mp3.

Hm, I interpreted the sentence that zc would import go-mp3.

Sure, we can do 1, but it would require an agreement between you and zc that go-mp3 would provide zc licensing and import guarantees.

I'm afraid I'd not change go-mp3 side. I think 3 is the way to go?

[wsc1]

Again, the benefit is interoperability with the functionality described at Zikichombo.org.

I'm asking the benefit to me.

Are you suggesting it is not a benefit to you to enable interoperability with the functionality described at zikichombo.org? In that case, we can proceed with option 3.

If you looked at the zc projects and want an explanation here, that is rather long-winded. zc is a project dedicated to creating a simple, reliable, efficient sound processing and I/O library in Go. the scope is I/O, codecs, audio dsp, and routing sound through sound processors. The status is it's new and in alpha.

If you are asking for some other form of benefit to you, I don't know what that would be and am open to suggestions.

[wsc1]

Sure, we can do 1, but it would require an agreement between you and zc that go-mp3 would provide zc licensing and import guarantees.

I'm afraid I'd not change go-mp3 side. I think 3 is the way to go?

SGTM

[hajimehoshi]

Are you suggesting it is not a benefit to you to enable interoperability with the functionality described at zikichombo.org? In that case, we can proceed with option 3.

I'm afraid yes since I'd continue to use go-mp3. I'm satisfied with the current oto and go-mp3, and there is no reason to me to switch so far.

[hajimehoshi]

If you are asking for some other form of benefit to you, I don't know what that would be and am open to suggestions.

I didn't mean that. I'm asking how I'd be happy with zc.

[wsc1]

Are you suggesting it is not a benefit to you to enable interoperability with the functionality described at zikichombo.org? In that case, we can proceed with option 3.

I'm afraid yes since I'd continue to use go-mp3. I'm satisfied with the current oto and go-mp3, and there is no reason to me to switch so far.

we can do option 3 then.

As a side note, the main reasons for me to use sio instead of oto are currently input, dsp lib, and prospect of synchronised duplex in the not too distant future. Others might have other reasons, who knows.

Thanks for the discussion and we'll put option 3 for go-mp3 on the zc roadmap.

[wsc1]

If you are asking for some other form of benefit to you, I don't know what that would be and am open to suggestions.

I didn't mean that. I'm asking how I'd be happy with zc.

zc is open to you to help it reach its goals as you see fit.

[hajimehoshi]

Thank you for discussing.

As a side note, the main reasons for me to use sio instead of oto are currently input, dsp lib, and prospect of synchronised duplex in the not too distant future. Others might have other reasons, who knows.

I'll revisit sio when I need such features :-)