BSD3 and distribution

Usage Questions
1

Forking over from the discussion from @jamesbradbury, @tremblap, and @groma in that thread, it would be worthwhile having a separate thread for this kind of discussion (particularly for when new users arrive).

The definition (found here):

Copyright {YEAR} {COPYRIGHT HOLDER}

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

  3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ā€œAS ISā€ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

So when distributing things, for example, the M4L device I linked in this thread, does that require the inclusion of a read-me file with the bundles (which can get confused with a generic read-me for the device itself), or does the ā€œā€¦in the documentation and/or other materials provided with the distributionā€ cover having them in the device as links/information and/or on the webpage where they can download it.

Iā€™m mainly thinking of distributing single devices like this, where Iā€™m unlikely to make a whole manual or comprehensive documentation for them, since they are fairly straightforward and self-contained (unlike some of my other patches). Particularly since there are no externals or dependencies to install, it would make the most sense as existing as a single .amxd that people can download and use. So can I have the info embedded in the code and/or on the webpage where it can be downloaded from?

2

These are certainly good pointers. I would not want a flashy logo to ruin your plug :wink: Seriously, you do not plan to have a readme nor a ā€˜aboutā€™ button? if you do, it has to flag the project, but if not, then Iā€™d have to check with the legal teamā€¦ although I reckon that in this case since people would need to open the patch to have access to the project stuff, we could do like Ableton did for the HIRT and leave it at that - it must have worked legally since I never heard backā€¦ although the EU lawyers might be more agressive, but the funding condition is all about open source tooā€¦

Iā€™m afraid to ask lawyers as I would not want to get a coercive answerā€¦

3

There will probably be an ā€˜aboutā€™ thing, but it will likely be on the webpage that houses all of the individual devices, and/or have a readme with a bundle download or something.

I was mainly thinking for individual devices (even like this, sharing it on the forum and whatnot).

I wasnā€™t planning on putting an about/credits on each individual device, since the UI is so small.

4

A text file with the distribution of the device should be sufficient for the purposes of meeting a the 3 clause BSD license.

The wording is with the distribution for binary forms (which will be included in the amxd) - I think it would be polite and probably the best thing to put a textile in the zip when they download (particularly if you think others might distribute it on again, as putting it on a website separates those things) - then youā€™ve done your bit. You can name the file (Flucoma_Externals_License) or something equally small, or add a small bit of text around the license without needing a full manual or docs.

As for @jamesbradburyā€™s question - if you donā€™t distribute the source or the binary that flucoma has provided then you can legally do whatever you want, because what you are distributing is your own - the BSD license places no restrictions on that.

Please note that in general 3 clause BSD does not require credit - there was something in the 4 clause version about that, but it was later removed to make things simpler in this version. @tremblap - if there are other reasons why the tools or the project require the project to be mentioned then it would be good to clarify to those who are relevant, as the BSD license does not enforce any such requirements.

The credits in the Ableton device were not there because they were legally required.

2 Likes
5

thanks for the thorough answer!

@groma @weefuzzy and I will read the small prints of the grant contract. I might ask the uni lawyers too. I think we must have acknowledgement so the funding can be traced backā€¦ weā€™ll make sure to sort that out

6

If that is the case, does that mean it would then have two ā€œlicensesā€ as such, particularly if it is a legally binding requirement?

And how far does that extend. Like if I make a blog about the stuff/piece/software, beyond obvious things like linking to the project and a license.md in the download, would I be required to have funding-related logos and stuff on my page?

Iā€™m all for giving credit to the project, but it starts to get a bit weird if the funding body itself becomes a function of the pass-long license propagation mechanism.

7

Not sure if this is a silly question, but shouldnā€™t the BSD3 license (with appropriate info and copyright date) be included in the download (and package) somewhere?

Or how is a user even supposed to know what kind of license is involved?

Or is it up to the user/developer to ā€œmakeā€ the appropriate license to include with any shared code?

(I just went to fully zip/package the Cloud device, and went to include the license based on the discussion here and couldnā€™t find it anywhere)

8

it should be and will be when we go ā€˜publicā€™ for realzā€¦ thanks for the catch!

For now, we are very soon RC1 so Iā€™ll let it floatā€¦

9

Ah right, I thought it was out out (hence my question yesterday).

10

cough cough

Any update on the ā€œactualā€ release of TB1?

11

yes indeed there are updates ;-).

1 Like
12

At the moment, we are polishing. With some beta users we found some bugs, and there was dangling issues of quality on a few objets (like my favourite and yours, AmpSlice)

If you let me know what object you are relying upon, and waiting to see if anything has changed, let me know what they are, and Iā€™ll see what I can do.

13

It was more the license thing and having somewhere to point to when I put out the M4L device(s). I think it uses primarily fluid.bufhpss~ (and .descriptors/.stats stuff)and some of the older stuff, so imagine (hope) that has all been working fine.

14

  • no change for most descriptors (melbands has a major change for the best but the others were ok)

  • hpss will be faster as per @groma work and might have a slight change of sound in modes 2 and 3 but I think you use mode 1 anyway

  • do you use any slicer? novelty, onset, amp?

15

No slicers in this one. Mainly hpss and transient (as layer separation).

1 Like