License and Distribution

[Michael Johnson]

Edit: After discussion below, the code will be opened under the Apache Public License 2.0. (Text verson for inclusion into the project source code.)

Original:

Once this project has reached a state where the Ruby code can be swapped out, it might be worth determining a license and if the code will be open for others to use. Although these are two different issues, they do relate to each other.

Note that we use a lot of the structure and XPath from the Ruby MAL API, so any license we use would need to be compatible with it. As it doesn't have a published license, we will need to contact the author for permission in using whatever license we choose.

I don't have a huge preference on the chosen license, but I'm against using plain GPL (it has weird interactions with scripts) or AGPL (restrictions on network services).

Personally, I think it would be a good idea to open up the code for contributions.

[Ratan Dhawtal]

To be honest I don't know anything about that licence 'stuff'. Mind to take care those complicated things?

I agree at the fact that a open source is a good idea. Few weeks ago an IOS app developer had some interest in our api. A few questions:

• Will we remove the UA on the open(source) code? (each app must have an own UA)
• Will we use bitbucket or github?
• Do you plan to make a documentation?

With remove I mean only the UA string. If anyone will use our api they will only enter their own UA and run the app.

[Michael Johnson]

I'd rather have agreement on a license than dictating it. It's a somewhat important thing and it's best to be informed. For some nice guidance, check out http://choosealicense.com/.

My thoughts on a few licenses:

• GPL: I don't like this for scripts because it mainly focuses on compiled applications. That can cause some interesting interpretations of the terms, and the FSF (creators of the GPL) tend to push to ways that increase the reach of the license.
• LGPL: Similar to the GPL, but it allows software under a non-GPL-compatible license to use the code, as long as they share the changes to the GPL portions. I like this better for scripts
• BSD/MIT: Very open license. Even allows someone to take the code and make a closed-source commercial product from it as long as they acknowledge the original developers.
• Apache: Similar to BSD, but adds patent grant language.

I personally like Apache, BSD, and LGPL, but there are many other licenses that are popular. For example, both the MPL and Eclipse license may be a good fit as they encourage sharing source without being as license-restrictive as the GPL. You can find more licenses here.

Onto the questions:

• The UA would need to be set by other users. It's already set up as a configuration option for the communicator service.
• I personally like BitBucket, but GitHub has more visibility and mindshare. Of course, there is no reason we couldn't do both and have a mirror on GitHub, but keep issues and other things logged over here.
• As I've been going through the code, I've been adding PHPDoc to the functions. I also have been investigating adding annotations for the API side to give a kind of auto-doc for consumers of the API. Were you thinking of other things?

Also, if opened up, we should add a readme with info on how to configure and set up the project, a contributions file documenting how to contribute including notes on coding style, and an authors file listing people who have made significant enough contributions to have copyright to parts of the code.

[Michael Johnson]

Additionally, if you don't want to read though all the license stuff, let me know what you want to require (no commercial sale, must share source, etc.) and I'll pick one or two options you can review.

[Ratan Dhawtal]

These are just some basic stuff :

• person who will contribute/use our api must not make money with it.
• Users can contribute and help us with adding features BUT they must be checked before we will insert it into our api. (checking: Look up if you doesn't use any codes of other api's without permission of the author who made it originally).
• Users are free to use our code but aren't allowed to modify/add function it and claim that he/she made it.(Exceptions: If we both give permission to that user)
• Everyone has the permission to run our api on their server/pc BUT they must refer to this api in their app/program/website which is using the api.
• If a users commit is accepted we are allowed to change the codes/features he made without his/her permission.

[Michael Johnson]

For point 1, blocking commercial use (making money) will be difficult. Most open source licenses don't block that, and none of the popular ones do. It would have to be either a custom license or one that isn't widely used. What is your concern about this point? The only commercial use I see for the code here is someone charging to access their install of it. Personally, I'm fine with someone charging for the public using their install - bandwidth and servers aren't free. That doesn't prohibit someone else from running their own copy.

Point 2 isn't a license issue. That part is just a matter of how the project is run. If someone wants to make modifications that aren't going to be put back in, they can do so in their own fork of the code. (Using an open source license means people are free to make their own fork and distribute that.)

Point 3 is easy enough. Nearly all licenses require that copyright notices remain in the code, so credit will still be visible to anyone who looks at the source. If it's removed, then they are in violation of the license.

Point 4 is along the same lines as 3. Credit is still required in the source code. For HTML-visible pages, we just add a notice in the comments. The person using it can still remove all active links if they want, but it is what it is.

Point 5 is similar to 2. We just don't accept any code back that isn't under the same license.

About the only point I see as problematic is point 1. Once I get the reasoning, I might be able to better determine what would work.

This might be a good explanation of the levels of licensing. It's really simplistic, but useful for a quick overview of the general levels of open source licensing. I'm personally fine with levels 1 and 2 on that page, but level 3 is an option if you really want (using AGPL instead of GPL, since this is a web service).

[Ratan Dhawtal]

Point 1: If a user takes our sources and sell it. Not hosting it for money or something else.

[Michael Johnson]

I don't see a huge problem. If someone wants to sell the source code, let them. It's open, so there probably wouldn't be a huge demand to pay for something otherwise easily accessible for free. If the seller removes the copyright or tries to disguise the source of the code by obfuscating it, they're probably violating some other part of the license already.

I could already see problems with that type of restriction, anyway. If someone hosts a copy of the code on their website and they get money from advertising on the site, would that qualify? You might say no, but they are getting paid for providing the code, even if it's not directly by the downloader or even all that much money. What if someone decided to make a CD with source code for different APIs or Symfony projects and sell that CD to those who want it? Obviously, it took some work on that person's part to find the software and structure the CD, plus costs of materials. However, it provides good advertising to the makers of the software on that disc.

I mean, I honestly do understand your concern, but it's not a problem I've seen all that much. Well, except for when the seller tries to disguise the source and thus violate the license in other ways. For those people, it wouldn't matter what the terms are because they'd just ignore them.

[Ratan Dhawtal]

Hmm okay,

I understand, do you got a idea what kind license we need(don't mind point 1) to use and can you contact the owner of the unofficial api.

I got the feeling that the api is ready for usage :D

(About bitbucket/github. I think we could stick with bitbucket.)

[Michael Johnson]

If we just want to keep credit intact and don't mind if the software is made commercial or used in a commercial product at a later time, the 3-clause BSD or Apache Public License are both great choices.

If we want to force changes to the code to also be released, the LGPL is a very popular license that has that term. It doesn't prevent it from being used in a commercial product, but does require that at least the component still be left open.

If we want to ensure that the code is only used with other (compatibly-licensed) open source code, the GPL is the strongest option, with the AGPL being even stronger (anyone that sets it up also has to provide source code downloads). Of course, people could still charge for the code, but the incentive isn't really all that big when it's easy enough to download it directly.

I'm fine with any of these choices. What option do you prefer?

[Ratan Dhawtal]

I don't want to force changes to be released and people to provide source downloads.

So I prefer in this case the 3-clause BSD or Apache Public License. After a while reading... the Apache Public License would be good.

[Michael Johnson]

Yeah, both the BSD licenses (in their variations) and the APL are really popular. I'll change this issue from proposal to task and edit the original post to reflect the decision for the APL.

The one thing waiting on is a reply from the creator of the Ruby API for license discussion. I sent a message via Twitter, but it looks like they are in Singapore (based on domain WHOIS info) so a response may not come until later. (Both the API site and his personal site are down at the moment.)

[Ratan Dhawtal]

I got the feeling that you send the message to his old account(he send a reply 5 hours ago to his friend)? Did you used This account?

[Michael Johnson]

License is all straightened out and I pushed 9b86914 to add the document and the documentation on every file.

Still need a README and CONTRIBUTING at the very least, along with a UA change. I have a commit pending for the UA change, but I'm thinking if there is a better way than how I'm handling it now.

[Michael Johnson]

Add Readme, Contributing Info, and Changes Info

Set up some basic documents for downloaders. Add a readme that explains how to set up code and links to the other documents. Add a contributing file that explains coding standards and desired contribution workflow. Add a changes document that details the differences with the Unofficial MAL API.

Ref #24

→ <<cset deef29ed28ff>>

[Michael Johnson]

Still need to switch to a distribution-friendly UA.

[Ratan Dhawtal]

I have a question about the COMPATIBILITY file. Is that the changelog (Changes Info)?

[Michael Johnson]

No, it's just a file listing compatibility notes/issues against the other API. For a changelog, one can pursue the commit logs.

[Michael Johnson]

Update the User Agent Handling

Make the user agent part of the global parameters.yml.dist This means that composer install will then take the dist file and prompt the user for values.

Additionally, remove unused parameters and clear the Swiftmailer config as we don’t use that component.

Ref #24

→ <<cset 56a65d9eaee8>>

[Michael Johnson]

Cleanup README and update with Install Info

Update the installation procedure documentation to reflect the creation of the application parameters file. Closes #24

Remove links to the various documents, they don’t work when displayed on BitBucket.

Cleanup list items so they actually display correctly, they need a blank line above to be parsed correctly.

→ <<cset cfdde1f81b7a>>