I want to make a BLE server in both android/iOS and also on a development board and I can't find relevant sources stating the legality on these standards.
The relevant source to look at is the Bluetooth Core Specification Supplement (CSS) which you can find here: https://www.bluetooth.com/specifications/bluetooth-core-specification/.
As you can see, it is very loosely specified. The Core Specification also does not say so much about the different AD types.
The spec says in the description "The Service UUID data type is used to include a list of Service or Service Class UUIDs." The spec then describes the different formats 16/32/128-bit UUIDs, incomplete or complete list. Other than that the spec doesn't say where this list comes from or what it represents. It however uses the formulation "If a device has no Service UUIDs of a certain size, ..." at one place. The spec though says that "16-bit and 32-bit UUIDs shall only be used if they are assigned by the Bluetooth SIG" so you can't pick any unassigned 16- or 32-bit UUID. So no you can not just pick any random 16- or 32-bit UUID, it must be an assigned one.
As in 1. the spec doesn't say which list should be advertised. But it is common knowledge that it should represent the list of GATT services that are present in the device's GATT database.
The spec for "Service Data" is very short. The description consists of one sentence: "The Service Data data type consists of a service UUID with the data associated with that service". For the data format it then says the data consists of the UUID followed by "additional service data". It is here, again common knowledge (I guess?) that the associated data must be defined by the specification of the particular service. for example, the Cycling Power Service defines the data as follows: "Cycling Power Service UUID followed by the Cycling Power Measurement characteristic value". So usually the associated service data consists of the characteristic value of a characteristic that has the Broadcast property enabled.
If the CSS is strictly followed (word by word), you could argue that it's possible to use a different list of service UUIDs than the ones in your GATT database. You could also argue that the manufacturer could put in its own "associated data" with a service in a Service Data record. I would say these are possible interpretations, but it's not what the one who wrote the spec intended.
The spec for "Manufacturer Specific Data" has the following description: "The Manufacturer Specific data type is used for manufacturer specific data. The first two data octets shall contain a company identifier from Assigned Numbers. The interpretation of any other octets within the data shall be defined by the manufacturer specified by the company identifier." This means you cannot "steal" another company's identifier and use a data format defined by you.
Note that Bluetooth is way older than the smartphone era. In the beginning, everyone that implemented Bluetooth was for the purpose of selling a product that uses Bluetooth technology (earphones, speakers, phones). Still at this day, when making a Bluetooth "product", you need to be a Bluetooth SIG member (which is free but only companies can be Bluetooth SIG members) and when you use any of the Bluetooth trademarks with the product you need to get it qualified and listed at Bluetooth SIG. You can read at https://www.bluetooth.com/develop-with-bluetooth/qualification-listing/ what actions and enforcements are taken if you fail to qualify a product. To qualify a product, you must follow the spec. There is a full test suite for qualification that you must pass. I'm pretty sure though it wouldn't catch if you use the wrong service list or "steal" a manufacturer's company id in manufacturer data. Developing software apps that run on already Bluetooth qualified smartphones is something that Bluetooth SIG hasn't thought of in my opinion. They have an option of qualifying as a "GATT-based Profile Client (app)" that costs $100 (https://www.bluetooth.com/develop-with-bluetooth/qualification-listing/qualification-listing-fees/), but that apparently isn't for you since you implement the Server profile. I have so far not heard of anyone that has done this app qualification. So to me it's a bit unclear how smartphone apps should be treated.
In the end the idea is that everyone should follow the spec to ensure proper interoperability between different products.
For your particular case, if you just want to minimizie the Advertisement data, just request a Company ID from Bluetooth SIG (it's free) and use Manufacturer Specific Data.