Improve clarity of library.properties include= field

[ianfixes]

Docs update

The existing wording for the library.properties field include= doesn't convey the fact that, despite literal reference to #include, this setting isn't a directive to the compiler.

The updated text (below) makes it more clear that the setting drives a convenience function in the IDE, where text is added to the sketch currently being edited.

includes - (available from Arduino IDE 1.6.10) (optional) a comma separated list, indicating the set of files that a sketch would need to include (as #include <...> lines) in order to use the library. This property informs the "Include library" command in the Arduino IDE, which auto-inserts those lines into a sketch. If the includes property is missing, all the header files (.h) on the root source folder are inserted.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[ianfixes]

My understanding of this contribution is that it's available to you under the terms of the GPLv3, the same license used by this project (which I forked).

Can you explain why the rights granted to you by that license are insufficient to accept my contribution?

[per1234]

@ianfixes there is some helpful information here:
http://contributoragreements.org/faq.html
This item seems especially relevant:

Why not license contributions directly under the respective FOSS (outbound) license (“Inbound=Outbound-licensing-model”)?
Inbound=Outbound is often used to refer to the standard model of licensing in the FOSS ecosystem and the release of standardized contributor agreements does not intend to change that. It is widely recognized that contributions are most straightforwardly licensed under the applicable outbound license. This makes it easy for contributors to participate in projects without the burden to read, understand and sign additional agreements.

Contributor agreements are complementary to the standard Inbound=Outbound licensing model. ... They also become relevant in case a project with a large community of different contributors wants to have more flexibility in terms of the respective outbound licensing model, such as license change, and more possibilities in terms of enforcement. With the inbound=outbound licensing model, FOSS projects cannot change the outbound licensing model without consent of each individual developer but can only make upward compatible changes to the outbound license. The inbound=outbound licensing model also puts the burden of enforcement of license obligations on the shoulders of each individual developer.

I realize it seems silly to go through this process just to add a few words to the documentation, but it's very fast and easy and only needs to be done once. I'm not sure what the process would be for you to get an exemption from our policy that every contributor must sign the CLA.

[ianfixes]

It may be fast and easy to click, but I have to run all this by my employer as well as decide whether I'm prepared to do this for all contributions, ever. I'm hesitant to contribute anything significant to a project that (by nature of this CLA) seems to reserve the right to make itself closed-source.

[alranel]

@ianfixes Sorry to answer after this long time - I had missed the notification. I understand you being hesitant, so I'll try to give some context here.
The purpose of requiring a CLA is to allow us to defend the project should there be a legal dispute regarding the software at some future time. This is common among open source organizations like Apache or Eclipse just to name a few: they all require CLAs for the purpose of achieving their goal of providing reliable and long-lived open source software and facing any potential license incompatibility that may arise in the future. In any case, we chose a lightweight CLA: contributors retain full rights to use their original contributions for any purpose. Also, in no way we can change license retroactively on code that is already published. We intend to keep Arduino free and open for anyone because this is our origin, our mission and our culture.

I hope this helps understanding our commitment and the purpose of this required "click" :)

[per1234]

Closing due to lack of signed CLA

[ianfixes]

The tone of this thread left a very bad taste in my mouth, and left me with less desire to contribute than when I first started. My question about the CLA was "why is the GPLv3 license on my code insufficient", and the answer was:

in case a project with a large community of different contributors wants to have more flexibility in terms of the respective outbound licensing model, such as license change, and more possibilities in terms of enforcement.

Unsatisfying and ominous (since even future adoption of the Commons Clause would be a step backwards in terms of rights). But this statement really bothered me:

I hope this helps understanding our commitment and the purpose of this required "click" :)

You are asking me to make a commitment in the form of a legal document, while your commitment is nothing more than a comment on a GitHub issue thread. The real commitment to open source here would be to simply use inbound = outbound, and abide by the current GPLv3 licensing on this project.