LICENSE?

[redchair123]

you know the drill

[afawcett]

I have BSD license embedded in all my files, however I assume your rather short description of the issue your raising here is to request I also place the license in a LICENSE file in the root of the repo, is that correct?

[redchair123]

In general, you should.

[afawcett]

Will take note, and do so, thanks for the feedback! :-)

[SCWells72]

Andrew, I'd like to include this in one of our managed packages that also includes a repackaging of apex-lang with Richard Vanhook's permission. This particular managed package is basically just the third-party libraries used by our own applications, and all of our other managed packages extend it. Since you've used BSD, it seems like that should be fine as long as we retain the license headers in the included class files, but I wanted to verify that you're okay with us doing this. Thanks!

[afawcett]

Yep no problem! Keep in mind global nails things in though. And they don't incrementally upgrade the metadata API, case in point last release they renamed a bunch of stuff. So this strategy will inhibit upgrades in the future. Likewise on other apex classes. Global is not ideal way to provide libraries, api's yes, but libraries that need to shift and move more not so good. Best I have done with apex commons on here is to prefix classes e.g fflib_SObjectDomian

[SCWells72]

Thanks, Andrew. I've definitely fought the global symbol restrictions battle, but I didn't realize that the metadata API was that fluid between releases. I think what I'll do is prefix all classes in the API with mdXX where XX is the version number of the metadata API from which the Apex client stubs were produced, and then I can evolve it over time more easily by deprecating an older version of the API if/when a newer version is introduced.