OIFM licence

[George Venios]

Hello,

During the Easter break I've built a fork of OIFM changing quite a bit of functionality. I've been meaning to make it open source too and publish the app on Play.
Since the work is now almost done, I've naturally been checking licencing stuff as I don't want to infringe in any way. From what I've read though an important issue has been raised. 
Since OIFM uses a licence notice on each file, and I could not find any general notice applying to the whole project, the files that don't have the notice are in fact unlicensed and a more restrictive licence can be applied on them at any later time, therefore forcing any forks to shut down or rewrite half the codebase. 
Please let me know if the Apache2 licence is supposed to govern the whole project and if so, whether I have the go to include a project wide notice on OIFM (Readme.md seems like the place for this) and remove any file specific notices, or at the very least let me include a notice on the files that don't have one. 
I would then pull the upstream to get the licences on my fork and properly attribute copyright to OpenIntents.

Thanks, 
George Venios.

P. S. Sorry for the double email, I used the wrong address on the previous one.

[Friedger Müffke]

Yes, Apache 2 is the license that would be valid for the whole project

--
You received this message because you are subscribed to the Google Groups "OpenIntents" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openintents...@googlegroups.com.
To post to this group, send email to openi...@googlegroups.com.
Visit this group at http://groups.google.com/group/openintents.

For more options, visit https://groups.google.com/d/optout.

[George Venios]

Great, thanks for the fast response!
Just to clarify: am I free to add the notice on any files missing it, directly on OIFM's main branch?

Thanks again,
George.

[Friedger Müffke]

Yes, and I would add a reference to APL2 in the readme and add a license file in the root next to the readme

[George Venios]

Just created a pull request on OIFM. Please have a look and let me know if this is what you meant. I can remove the file-specific notices (before merging) if you want to reduce clutter as they are probably now redundant.

See https://github.com/openintents/filemanager/pull/48

[aap]

George,

Just curious: what makes you prefer to release a fork rather than submitting the enhancements to OIFM itself?

Regards,
-- Aaron

[George Venios]

Aaron,

I actually thought about it before starting work on the fork. The main reason was that working directly on OIFM would impose constraints on how much functionality I could remove and how different the end product would have to be. I wanted to remove parts that I perceived as central, such as some intent stuff (e.g. it no longer exposes other app's actions on files through a "More" button). I've also wanted to remove backwards compatibility - my fork is only currently compatible with 4.0.3 and up, and even that will probably be bumped up in the near future. Another big reason was the fact that I wanted to experiment a bit with branding. Last but not least, a major goal was to make a file manager that would perfectly suit my personal needs but still offer it for others to use if they like it. 
Even though all my other projects are closed source - and I considered this one to become such too - I made the decision to publish the code since I've implemented some fixes that could relatively easily be applied to OIFM, and even if not for these immediate ones, I figured that OIFM would benefit from being able to pull back future fixes/changes as needed. 

Hope this answers your question :)
George.

--

[Friedger Müffke]

Great! Love it!

[George Venios]

Great to hear that!

Could you please confirm that you want me to remove the per-file license notices on OIFM so that the pull request can be accepted? I want to make sure we're on the same page before proceeding with open sourcing :)

Thanks,

George.

[Friedger Müffke]

I don't know the difference of having a per file licence and project licence. Any insight?

[George Venios]

From what I've read it's effectively the same. I understand that having a project-wide notice is just easier, and applies to all source material on the project - regardless of form. Also, according to my research, per-file notices are used when the file is likely to be shared as a single entity. The requirement for the ASL2 to be effectively applied is just that source material under the license contains the notice; meaning that it does not really matter if such a notice is in the root of the material, or on all files.
The only other case I would see per-file being a good choice is if different licenses apply for different files, which is not the case here as far as I understand. 

Please correct me if I'm wrong on the above, maybe Aaron or Al know more on licensing?

[George Venios]

By the way (sorry for the double post), from what I'm seeing on other projects (e.g. Square's ones) I think it's perfectly fine to have both types on the project. Just let me know what you choose so that I finalize and merge the pull request :)

[Friedger Müffke]

You can remove the headers in the files...