Hi @sereda, those are all fantastic questions. I want to answer them all, but some of them are above my station, so I’ll answer what I can now and see what can be answered later.
Thanks for flagging this. Obviously, the AUI team wants AUI to be a useful and usable choice for you when you’re building UI for our products. When choosing the license for AUI, a scenario wasn’t considered where the UI layer was built for multiple ecosystems. I’ll take this feedback to the Atlassian design and legal teams and see what can be done.
A tradeoff was made to allow a small team (think <= 2 people) to work on implementing design and behavioural changes in AUI. The tradeoff may be the wrong one to make - in my eyes there’s no point in improving AUI’s usefulness if the licence prevents or deters a portion of the ecosystem from using it. Again, on this point, I’ll take the feedback to the relevant teams and see what can be done.
Allow me to offer the technical rationale in the meantime.
Technical backstory of the decision
AUI started life as an HTML+CSS pattern library circa 2008. Over time, it evolved in to a more dynamic component library. The AUI component APIs are not always consistent, nor easy to consume, especially compared to more recent (web-)component libraries such as Polymer’s Iron Elements.
To make AUI easier to use, it would be best for AUI would to transition to web components. Since they are standards-based, web components have the largest portability potential and are the least opinionated or restrictive in terms of framework choices that can be made around them.
So, the plan is to iteratively add web component APIs for all AUI components, and make individual components consumable rather than a monolithic library.
Now, AUI’s current (6.x) architecture has two significant roadblocks to executing on that plan:
- AUI’s code architecture separates by technology instead of purpose – i.e., there are folders for
js/andcss/, but not fordropdown/orbutton/. - This architecture choice underpins the “theming” approach for the AUI library – i.e., any files or folders in the “aui-adg” repository should shadow or override the ones from “aui”.
It is not possible for a small development team to move to a proper component-based model without affecting this architectural structure. Thus, the decision to merge the repositories.
Future plans
As I mentioned above, the plan is for AUI to have web components as API for all of its components, consumable individually.
Under this model, we can do something similar to Atlaskit’s current implementation: each component can ship as its own package, which is individually licensed.
Putting aside the “why” for now, what seems reasonable to me is that the web component APIs would be licensed under a permissive open-source license (i.e., Apache-2.0) whereas the “design” of them is pulled in from a separate package which is licensed under the ADG license. I would assume this arrangement would allow fair use of the components for building your UI, provided that in the non-Atlassian environments, the AUI components were modified to remove the ADG-licensed dependencies.
Where to from here
Let me know if the future plans I outlined above sound to you: reasonable, beneficial, pointless, confusing … whatever.
For right now, the AUI license is still changing. I will however reiterate that the only license for AUI 7+ will change; the component APIs in AUI 6.x will remain under Apache-2.0. Existing JavaScript-based and HTML pattern APIs would remain largely unchanged between 6.x and 7.x, so compatibility with Atlassian products on 7.x should be there if you chose to build your UI using 6.x.
I’ll take your feedback to the design and legal teams and we’ll see what can be done to ensure AUI remains a viable option for you.
Cheers,
@daz.